You Gotta Stand Up For What You Believe In

Built To Last and Good To Great left me with a lot of ideas to digest, but I'd like to touch on two of them. In Good To Great, part of the Hedgehog Concept involves the journey in finding the "core" that you believe in. In Built To Last, half of the foundation for building a visionary company is "Preserving the Core."

How do you find the core? It has to be something you're passionate about. Philip Morris is passionate about offering products and defending your choice to use those products. You may not agree with that stance, and if that's the case, working at Philip Morris is probably not a good idea. Nordstrom's is passionate about customer service - almost fanatically so. If you aren't, you won't fit in.

These companies spent a while looking for their core values. Once they found them - they were passionate about keeping them, and developing a company where the values would flourish, by hiring (and keeping) individuals who shared those values.

This is of the utmost importance. At the point where you're looking for employment in your life, your core set of values is probably established. It becomes harder to change these as you grow older. Don't be afraid of what you truly believe in. If you're passionate about something, find and surround yourself with others who share these values. By the same token, a company should actively seek to hire individuals that identify with it's core values.

For software companies - I think there is a key difference between core values and core competencies. I feel far too many recruiters and jobs focus on technical skills that can be acquired by any good developer in a few weeks. Focus on the values the developer holds. Are they disciplined? Are they enthusiastic? These are more important, as these traits will drive them to always be learning the technical skills they need to help them succeed (and your business, as well).

Disclaimer: There is still a core level of technical competency that any developer needs. I think it's hard to really quantify it, but anyone working as a developer definitely needs technical skills. They are, after all, what allows us to do our jobs. I just don't feel that measuring someone solely by their laundry list of buzzwords on their resume is a good indicator of their true worth.

Software Companies and Discipline

Anderson brings up to my next point - what would you consider discipline in a software company?

The first discipline concept is Disciplined People. Most top-notch software shops know how to hire disciplined employees - individuals who never stop learning, and who are committed to building (and shipping) great software. You want everyone on board to be serious about their craft (whether it is a developer, tester, or manager). They need to have both the guts and the ability to take your company to Great (as capitalized by Jim Collins).

The next concept is Disciplined Thought. You've hired the right people. They have the raw abilities, and they have the gumption to perform at their best. Now, comes the unified part. You have to harness all of that discipline and focus it on your software. This is hard. You need to create a sense of unity. It's not the testers vs. the developers. It's not management vs. everyone else. The entire team needs to be "signed up" to deliver Great software. Again - if you've got Disciplined People, this part should be cake.

Finally, there's Disciplined Action. This is definitely the hardest part to "get right." It's crucial that the first two ideas happen before this one can be truly successful. I myself have a hard time with it - undisciplined thoughts that turn into actions can make it look like it's a failure in execution, rather than planning. (Especially when you have several successes under your belt.)

Developers are notorious for being bleeding-edge adopters. It's practically a badge of honor to be running nothing but beta software on one's machine. I'm no exception - it's happened in the past, and right now I've got two different versions of Visual Studio running side-by-side. What happens is if you let this tendency run wild in your software, you will have problems. I'm not saying new technology is a bad thing. I can't wait to replace some of my Dictionaries with HashSets. LINQ is undoubtedly cool. And don't get me started on lamdas. But, there's no way I would try to integrate .NET 3.5 into an existing project that needs to ship anytime soon. I've been down that road before, and I know where it ends. (Hint: it's a particularly "deathly" kind of "march.")

You get the right people, who will make the right decisions, and execute them properly. For a software company, this means hiring people who will ship great software, and base their decisions and actions around that concept. Developers write high quality, unit tested code. Testers make sure the code meets requirements and is of high quality. Managers keep the machine running smoothly, and block any attempts to foul it up. Business analysts figure out what the customer really wants. And no one makes decisions that will run contrary to the desired outcome - shipping Great software.