Tue 30 Dec 2008
Recently I found myself in an uninspiring company meeting listening to a consultant drone on about what he felt were essential elements of successful software companies. He and I had both been hired to help this small, growing company buttress its revenue stream. The last thing I remember before I fell asleep was his blathering about the lessons he learned from the dozens of companies he had helped bury.
I’m not normally a cynic and I recognize it’s easy to dismiss others’ ideas as out-of-touch or impractical to implement. Pointing out deficiencies is not hard at all. A colleague of mine once reminded me that the burden of the complainer is to propose viable solutions to the problem.
Now, unlike the speaker, I was hired for tactical consulting, not strategic, but I thought of what I might be able to say in front of these twenty five developers, sales reps and customer support engineers. What are the core principles of great software companies?
Back in my MBA classes at the University of Utah, I concluded that it’s impossible to provide a formula that guarantees business success; there are just too many non-deterministic factors at play (timing, market conditions, actions of competitors, etc.) It is possible to list the common elements of thriving companies and to highlight the pitfalls you must avoid. Here is a brief list of some elements and principles I’ve found to be in place at great software companies:
Robust Software Framework
- Reusable code/modules
- Object oriented architecture
- Services oriented architecture (interconnectable)
- Error handling
- Debugging
- Profiling
- Database abstraction
Well Structured Environment
- Version control
- Code to tests
- Ticketing system
- CMM/ITIL process management
- Clear release process
Cultural Values
- Mutual accountability
- Productive conflict
- Trust
- Where possible, Keep It Simple
- Work ethic
- No hackery– be proud of code
- Document! (all knowledge: code, methodologies, systems, etc)
- Always add value
- Don’t reinvent wheels (unless it’s a much better wheel)
- Use standards where they make sense
- Data security and backups, anticipate hackers
Misc
- Under promise, over deliver. on time.
- Customer-driven features
- Quality Assurance with automated tests
- Fast, Clean, Simple, Intuitive interface that just works
- Fast/Agile
- Scalable, Fault-Tolerant Architecture
- Team-oriented
- Hire and retain excited, passionate people
- Growth focused
What did I miss? Would my presentation have been as lame as the one I fell asleep in? 
I would also submit that you absolutely need a management team who understands what the above bullet points actually mean with relation to the tasks assigned to the developers, milestones, etc. I’ve been in many companies where much is professed to conform to your standards above and the reality is starkly different. Long story short… don’t work for someone else.
Ryan,
While I concur with your points about the ideal, how do you transform these into the practical. Having been part of a company who juggled many elements:programming, sales, customer service, egos, great friendships (loyalties), great and poor execution, I find myself pondering how do you make the ideal, practical. If money were no object and you could feasibly juggle all the elements I mentioned, I believe you could arrive and as BJ mentioned, you could put in place realistic time lines and a solid infrastructure. However, when you need sales to generate revenue to pay the developers who are producing the product and sales are not where you need them…what do you do?
In analyzing this further–I feel like we often get to big for our britches and we think we are bigger than we are. The company I was in paid a lot of money for programming–and each time a new programmer was hired the code was degraded as “junk”–other words were used but suffice it to say that the programmers only seemed confident in their own coding.
As I have seen in numerous companies the upper management wants the machine to fly before the wings are built–because of potential. The developers want it on the ground because of execution. I was in a meeting with a prospective customer discussing possible marketing solutions and he said, “yeah I sold that last week at a seminar and now I have the developers working on developing it.” (no it wasn’t JR or AT)
As I look to the future and future endeavors, I want to make sure I know how to balance this element.
FYI I found this on Silicon Slopes
Here’s some more:
A company that pays their employees without having the employee hunt down the one of the owners for his check. A company that doesn’t come up with some lame excuse why they didn’t pay their employees. Just be honest.
A company with people that actually does what they say they’re going to do. If you promise your employees things, follow though. If you can’t, be honest and stop paying games.
A company that trusts it’s employees and isn’t looking over everyone’s shoulders counting how many instant messages they’re sending a day.
Selling before developing in it’s self isn’t a bad principal as long as the client knows that it’s not done yet. Where you get into trouble is when you sell the product and tell the client that it’s done, when it’s really not but telling them that it’s undergoing maintenance at the moment. People aren’t stupid. They’ll figure it out faster then you think.
Lying to clients isn’t a good way to generate revenue. Once you lie to a client, that trust is gone forever, your reputation is destroyed and it’s extremely hard to rebound from that. Most never do. The company will end up in the ground, like this one company that I once worked.
You bring up a good point, Alex and I wonder what would happen if you apply the same theory stated in your last paragraph to a social relationship. By social I mean boy, girl. And by same theory I mean once you lie, no matter the size or relevancy, is trust gone forever? I agree that a recovery is extremely hard but does a loss of trust mean all is lost?
Sorry to stray from the point, boys – but I honestly wonder….