<commit_before>---
layout: post
title:  "Team Build Advice From The Wise Web"
date:   2016-03-10 
categories: organization 
tags: idea concept
---

Building a team is never easy. I have been a member of software engineering team with differing culture in my career. 

I started from being a member of a highly structured hierarchy where each individual has a specific designation and organizational position and a specific set of roles and responsibilities. This organization is mature enough that it has its own new-hire package; an HR took me to meet everybody in their cubicles, my manager gave me a training schedule to introduce me to the specifics of their products and to the standard practices I must follow, from HR policy to IT policy to Software Engineering policy. I did not have much freedom to interact directly to anyone in the organization, maybe because I did not have to, but I was content to know that they are reachable if I need them. I ended up to only reach a specific number of people: my two mentors who guided my work and my manager to whom I report. 

I later joined a similarly organized team where I was made aware of the scope of my teammates scope of knowledge and responsibilities. It was a more 'barrier-free' culture where I could freely walk around the office to reach the people I need to get my work done, be that my CIO, Software Engineering Manager, Business Analyst, QA teammate, Business Process teammate, Database Consultant, or Network Engineer. They gave me insights and feedbacks to help me complete my work.

I then joined a team that has no clear and organized hierarchy, or as some would say, an organic and dynamically structured team. I ended up doing everything in my power to get things done, and by anything I mean taking multiple roles and responsibilities not specific to one designation, and I gained a lot of skills and confidence to play the position I did not apply for in the first place. I became more than a Software Engineer because I was exposed to, and involved in, so many dimensions in the organization to a point that whenever someone asks me what I do there I ended up saying "EVERYTHING!" (which is not exactly true, but close enough).

Which one is better? I don't think this is a good question to ask. Is an apple better than an orange? To an apple farmer, an apple is better because it gives them money one way or another.

To build a team, I came across a lot of insightful remarks from the wise web (to name a few: <NAME>, <NAME>, <NAME>, <NAME>):

> It doesn't matter how good you are if you are working on the wrong problem at the wrong time using the wrong approach.

And then another:

> Top three reasons why Startup fails: No market need, ran out of cash, and not the right team.

Then:

> Do not lower your standard no matter how hard to find those candidates. It is better to reject good people than to hire bad ones.

Interviewing, hiring, and team integrating are unfortunately not an exact science. It's more of a gamble, gut feeling, psychology, and a touch of maths and logics. I have hired a number of people in the past few years and I have learned a lot from my mistakes and achievements. In order to move on and grow my team, I have applied a mix of OODA loop and Kaizen techniques and the result has been fruitful.<commit_msg>edit team build post<commit_after>---
layout: post
title:  "Team Build Advice From The Wise Web"
date:   2016-03-10 
categories: organization 
tags: idea concept
---

Building a team is never easy. I have been a member of software engineering team with differing work culture in my career. 

I started from being a member of a highly structured hierarchy where each individual has a specific designation and organizational position and a specific set of roles and responsibilities. This organization is mature enough that it has its own new-hire package; an HR took me to meet everybody in their cubicles, my manager gave me a training schedule to introduce me to the specifics of their products and to the standard practices I must follow, from HR policy to IT policy to Software Engineering policy. I did not have much freedom to interact directly to anyone in the organization, maybe because I did not have to, but I was content to know that they are reachable if I need them. I ended up to only reach a specific number of people: my two mentors who guided my work and my manager to whom I report. 

I later joined a similarly organized team where I was made aware of the scope of my teammates scope of knowledge and responsibilities. It was a more 'barrier-free' culture where I could freely walk around the office to reach the people I need to get my work done, be that my CIO, Software Engineering Manager, Business Analyst, QA teammate, Business Process teammate, Database Consultant, or Network Engineer. They gave me insights and feedbacks to help me complete my work.

I then joined a team that has no clear and organized hierarchy, or as some would say, an organic and dynamically structured team. I ended up doing everything in my power to get things done, and by anything I mean taking multiple roles and responsibilities not specific to one designation, and I gained a lot of skills and confidence to play the position I did not apply for in the first place. I became more than a Software Engineer because I was exposed to, and involved in, so many dimensions in the organization to a point that whenever someone asks me what I do there I ended up saying "EVERYTHING!" (which is not exactly true, but close enough).

Which one is better? I don't think this is a good question to ask. Is an apple better than an orange? To an apple farmer, an apple is better because it gives them money one way or another.

To build a team, I came across a lot of insightful remarks from the wise web (to name a few: <NAME>, <NAME>, <NAME>, <NAME>):

> It doesn't matter how good you are if you are working on the wrong problem at the wrong time using the wrong approach.

And then another:

> Top three reasons why Startup fails: No market need, ran out of cash, and not the right team.

Then:

> Do not lower your standard no matter how hard to find those candidates. It is better to reject good people than to hire bad ones.

Interviewing, hiring, and team integrating are unfortunately not an exact science. It's more of a gamble, gut feeling, psychology, and a touch of maths and logics. I have hired a number of people in the past few years and I have learned a lot from my mistakes and achievements. In order to move on and grow my team, I have applied a mix of OODA loop and Kaizen techniques and the result has been fruitful.
{'fraction_non_alphanumeric': 0.031578947368421054, 'fraction_numerical': 0.002406015037593985, 'mean_word_length': 4.159813809154383, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5997112', 'n_tokens_mistral': 1556, 'n_tokens_neox': 1497, 'n_words': 1179}