High functioning teams
Over the last week on the ALT.NET list there has been a discussion about the "expert" ALT.NET'ers joining forces to form the best IT consulting business. This idea is not a new one. Many have discussed this in other venues and some have acted on it. Recently, Martin Fowler wrote about PreferDesignSkills. This is not a new idea either. What is common between both of these discussions is the focus on the individual. For the first 20 years of my career I fell into the "best individual" camp, however over the last 10 years I have been in the "best team" camp. This change in thought can lead to very different hiring practices and company culture.
When interviewing a candidate I start by evaluating the person on the things they claim to know. If you don't know what you claim to know or are as good as you claim to be in that area then that is grounds for immediate rejection. Next, I evaluate the candidate for capacity and willingness to learn. This is where Fowler and I start to disagree. Fowler values design skills above anything else, as far as I can tell. I take a much broader view. I value candidates with a strong foundation. Design skills are important, but they are just one part of the foundation. Regarding capacity to learn, I am looking for someone who can reason about a new method, technology, process, tool, etc. and develop an informed opinion about if and when to use it. If the candidate only believes in the "one true way" or "one true tool" then they have lost their capacity to learn, at least in that area. Regarding willingness to learn, I am trying to determine how self-motivated the candidate is to learn new things. Next, I evaluate the candidate on their ability to make a team better. Is this candidate willing to play a specific role on the team? Will this candidate help make other team members better? Will this candidate be respectful to other team members? Will this candidate show loyalty to the company, project, and customer? Finally, I try to form an assessment of how much of an investment is required before the candidate is a contributing member of the team.
Getting back to Fowler's design vs. platform skills choice, there are a couple of problems with his conclusions when you look at it from a team point of view. First, what are the skills that are required to round out the team this candidate will be put on? If the team doesn't have all of the skills necessary for the project to succeed then I believe the most important thing is to fill the holes in the team. It is easy to say that you are hiring the person for future and not for the project, but if you put a person on a project that they aren't a good fit for then you haven't done the candidate, company, project team, or customer any favors. Putting any butt in any seat doesn't work, in my opinion. Second, I don't believe that you can make a blanket statement "that a good programmer should be able to pick up a new platform relatively quickly". Some projects require solving hard problems and that may require a deep understanding of the platform. Third, Fowler shows clear bias in design or platform skills. He implies that platform skilled people will never be able to acquire design skills or at least not easily. After a couple of years working in Microsoft Consulting Services I have a very different perspective. I can match his horror stories one-for-one like ripping out 1,000 lines on non-working Spring.NET code and replacing it with 20 lines of .NET platform optimized code or reliance on Rational XDE design-generated code resulted in a sub-optimal .NET solution that required substantial performance tuning or a sub-optimal data access layer that failed to leverage any of the features of the DBMS. My point is not that platform is preferred over design, it's that both play an equally important role in the success of a project.
NOTE: I have nothing against Spring.NET. It is something that I have used successfully, but in this case it was used when it wasn't necessary and it was used incorrectly. The person who wrote this code was a design-focused person who was looking implement IoC and AOP everywhere and into places where it wasn't needed to meet the requirements.
There is a perpetual debate that goes like "1 top-2% developer can outperform 10 bottom-50% developers". You can replace any of the four numbers with whatever you want, but the story is the same. A highly-talented person can outperform a bunch of below-average people. As Craig Andera said at our last ALT.NET meeting, by its very definition we are always going to have many more below-average than highly-talented developers. I've been there and done that. I've been the top developer that outperformed X other developers. So, what good came from it? Certainly, my customers appreciated the efforts, but the team didn't. There are only so many hours in the day that a highly-talented person can work and because there are so few of them it isn't a scalable practice. When I left a project the team wasn't able to continue on the same path or velocity because they didn't get it. When the customer finally realizes the maintenance issues it is too late. Is there something better than this? I think so and have been increasingly working differently over the last 10 years. Instead of stating that I can outperform X developers I ask "How can I make X developers and the team as a whole more productive?". I don't have any numbers to support this claim, but I believe this change in attitude can lead to higher functioning teams. I believe the "outperform" attitude causes you to write off a bunch of people unnecessarily. As in any industry, the IT profession has some useless individuals, but I think the number is a lot less than elitists believe it is.
Back to the original question, can a bunch of experts join forces to form the best IT consulting business? It is certainly possible, but I don't believe it is probable and its certainly harder than forming a corporate structure. I believe the question is too focused on the individual. It takes a lot more than individual effort, no matter how expert, to build the best company. It takes a lot more than individual effort, no matter how expert, to grow beyond a small company. High functioning teams are an essential ingredient to building the best company.
4 Comments:
Interesting post.
I hadn't read any of the ALT.NET discussion, but after following your link and giving it a fairly quick scan, I should note that I'm mostly turned off by such talk because it is so self-serving. Am I to believe someone is a great software engineer if they belong to ALT.NET? Belonging to any group--and I don't care what group that is, whether it be my own company, Martin Fowler's company, being an alumni of [insert prestigious university here], etc.--has little to do with whether a person is truly talented at the number of skills that make a team go or, to further your point, whether s/he can help a certain team working on a certain project.
As I ponder my above statement for a moment, I think of the far reaching realities of it. Say, for instance, I am dealing with a member of a very, very exclusive group: for the sake of the discussion, let's assume we are dealing with an IBM fellow. Can I still make the above statement? I believe I can. Such a person is surely intelligent and likely to be a relatively profound thinker, but does this person have the human skills that really propel a project? Will team members like this person? If they don't like this person does it matter? Will this person check their ego at the door? Will this person help the project beyond a purely technical level? Do we need such a person to help the project in a way that is beyond a technical level? Maybe, maybe not. Every project is unique and every person unique, and every moment of every day brings forth new challenges that a team must adapt to if it is going to raise the bar of excellence.
Getting back to the question at hand, "Can a bunch of experts join forces to form the best IT consulting business?" I'd say that yes, it is possible but it isn't probable. There are way too many human elements involved (i.e., sheer complexity) to think it's a simple equation. Every person involved brings in an infinite number of variables that are impossible to fully examine or predict how they will interact with other variables. The best you can do is to keep an open mind, stay focused by hiring for the task(s) at hand, and take an educated guess.
I do believe the general context of your post is spot on, though. Once you cling to one skill over another or once you cling to one philosophy over another, you are static and you are dead. I don't think that Fowler's intention was to be so static and was instead intended to stay focused on his general inclination of favoring design skills over specific platform skills. I agree with him, generally speaking. I've worked with way too many, annoying people that are deeply involved with a platform and that know a lot of the arcane ins-and-outs of it, and although they are able to turn heads (usually uninformed heads that end up with decision power) in meetings with proposed, off-the-cuff solutions, they really don't gather much merit from me. I prefer someone that knows how to engineer a system, that knows how to implement the design, and that knows how to do both in the simplest way. And this is the reason I also currently prefer small teams with excellent engineers--it's much more fun to build something together. Besides, as technology grows, I can get a lot done with a small team that wasn't possible in days gone by. That's not a knock against larger teams because there is certainly a time and place for them, but it then becomes a completely different set of problems you are faced with solving...and I'm not particularly interested, at this point in time at least, in such problems.
Steve,
I don't believe that design skills (design patterns, TDD, agile methodologies, etc.) are a better indicator of success than platform skills. Both of them provide just a fraction of what's nessary for a project to succeed and both are often necessary for success. I believe that design skills are very important skills to have, but I have seen as many design knuckleheads (as platform knuckleheads) sink a project.
I hope that the IT industry will mature to the point where we have better indicators for project success, but we have a ways to go.
I guess it depends on what you mean by "skills." When I say skills I mean the person actually has real, tangible skill in terms of engineering a system...and not necessarily the ability to recite a pattern or to recite the tenets of any particular methodology. I've heard a lot of talkers in the profession but I haven't met many people that can back it up by working hard and continually cranking out effective code day in and day out.
But, again, your point is well taken. What resource is needed really depends on the project, depends on the timeline, depends on what resources are currently available, etc. However, I have met extremely few people that have a good sense of engineering and the ability to get their hands dirty working quickly in the code within a given platform. I've met a lot of people that can talk the design game, and I've met a lot of people that get dirty in the code (and consequently make the code dirty), but not many that can combine both to really move a project (or simply a task) forward at a good, stable clip.
I also haven't met anyone that has a really good sense of how to build a system that doesn't get their hands dirty on a regular basis. In my mind they go hand in hand. The whole notion of an "architect" that oversees things without keeping their hands in the code is a delusion, to me. Maybe for a short time it can be done, but if such a person stays away from the keyboard for too long their design skills will fade quickly...or even before their skills fade their connection to the team and the project will fade.
If the person doesn't have a good sense of design, then they will only make a mess, anyway. It might make a certain project hit a timeline in the short term, but not in the long term.
Great work.
Post a Comment
<< Home