I was listening to a podcast on Agile Staffing last week and they succinctly stated a couple things everyone sort of knows but doesn't say that often.
- On small startup type teams, the team is everything, a bad team member can kill the product and the company.
- On particularly agile teams, having agile people is better than having technology experts.
The first point is really clear, be it the leadership of the team or contributors to the team, if any one piece is broken then the whole thing won't work well. The second point is something I think people tend to dismiss, people like to list desired skills in job descriptions more so than desired attitudes and in an interview it's far more likely you'll be asked to write some code or explain some sort of process than you will be given a personality profile.
One pattern that I've seen at a number of companies I've worked at is that new people will be some how challenged and asked to do some heroic amount of work and the company sort of over reaches. After that challenge project is done the team never fully recovers, the team is skeptical of everything and doesn't want to work that hard again. All future projects are exercises in work reduction, not so much in product improvement. The team is reluctant to do anything like the challenge again. You end up with something that's fundamentally not repeatable. Even if you end up with a great result, the team is fried and you can't follow it up.
Another pattern I've seen is the so called "analysis paralysis." The desire to find a singular, "perfect," solution to a problem outweighs the desire to do anything else. Rather than attempting to fix problems or "solve the problem multiple times," or put "band-aids" on problems there is a desire to wait until an ultimate solution is created, which is usually never. With the problem, there are usually some fairly easy things that can be done to make some sort of incremental improvements along the way.
Back to that second point, there are personality traits that help you find people that help you break those patterns. There are people that are willing to iterate on solutions and try to repeat success and those are the people you want to put on teams. Now this is all software talk but does it apply to security and network teams? Is a security policy something that has to be iterated on and changed over time or is there a "perfect" solution that can be reached? You can have the best security guys in the world working for you but if you've overextended them do they still actually work?
