I've worked at and consulted for quite a few tech companies, successful and unsuccessful, and observed quite a few cultures.
It's a term with a pretty fuzzy definition, so it's hard to know what you mean when you say "culture" and if that's the same as what anybody else means. And the concept also gets muddied by all of the business how-to talk about it, as if you could just tell a bunch of people "Our culture is to sit on thumbtacks and like it" and people would then actually do that.
Culture is largely a set of assumptions about how to behave and what to value, and it is usually communicated indirectly - nobody successfully codifies their culture and turns it into a one-pager to hand to new employees. Culture is what people do and the habits of thought they have that drive their choices about what to do. That gets picked up by new employees by watching what actually happens and reading into that what is expected of them.
But most importantly, culture is a process - it's a living breathing thing that gets altered a little bit by every participant in it. Attempts to bottle a culture and preserve it as a static thing wind up killing the thing they seek to preserve. You will be able to start things out on the right foot, and set a powerful example, and use your power as a founder to right the ship if it evolves in ways you disapprove of. But think of it as more like steering a ship, or gardening, than a coat of paint you roller onto your company in its early days that will be there for eternity.
Your question "should this be addressed" sounds like you think it's more like paint. Your culture is what you do and say, what people read into that and emulate, and what they do and what others read into that and emulate. So hire well, and when interviewing try to get a sense of the things the interviewees care about and value, because those things will become part of your culture.
Here are some aspects of the culture of successful organizations I've been involved with:
- Trust - people rise or drop to expectations of them, and this is more communicated by behavior than words - if you tell someone that you trust them, but then micromanage them, the lesson is that you don't actually trust them, you just like the sound of saying you do; they in turn will need to micromanage anyone under them to report adequately to you, and you've undercut trust across all levels of your organization.
- Directness - the most effective manager I ever saw took what Americans would call an "asian parenting" style to his management. If you failed at something, his first words to you the next time you met would be "You failed." Then you'd discuss why that happened and how to do better next time.
- Code/Work Review - nobody should be able to think "nobody is looking at what I do" - at one company this simply took the form of one brilliant developer who simply read every line of every diff committed to a huge codebase, and pointed out (on a mailing list that hit everyone) when something could be improved or was wrong - and did so in a matter of fact way.
- Gentle but Firm Intolerance of Bad Work - in software developer organizations, this usually takes the form of soft hazing of sloppiness or complexity-for-the-sake-of-complexity.
- Interest in the Customer - valuing and taking pride in creating things customers will like - which only happens if there are metrics and feedback paths from customers to the lowest levels of the organization, so people see their impact. Otherwise it's easy to put blinders on and think "my job is to implement feature X" and churn out whatever can be done fastest.
Here are some aspects of the culture of organizations I've been involved with that either failed or righted their ship only at great cost:
- The Great Man Syndrome - having a founder or architect who has stopped learning but whose decisions may not be questioned. Engineers wind up investing their time in workarounds for bad decisions, and that becomes what the culture rewards; those workarounds raise the cost of implementing anything new.
- Inability to Acknowledge Failure - if you have a culture relentlessly determined to be "positive", you wind up with maladaptive behaviors like rewarding teams that produced something that doesn't work because they met their deadlines. And protecting people from knowing that they failed because saying that is not nice robs them of the opportunity to learn from failure. Note that anger is not helpful, but honesty is.
- Design By Committee - every successful project - be it a product or a startup-within-a-company had one consistent characteristic: A team of 5 or less people were empowered to design and implement (or prototype) it, and their decisions were law.
- Methodology X Will Save Us Syndrome - the idea that a set of rote rituals is a substitute for having and watering and weeding your culture. Methodologies are products, which are sold by people who have no stake in your success.
- Everything Is Broken - people joke about how broken the product is, but do nothing to fix it because either management has illusions they will be punished for dispelling, or attempts to fix it are met with disapproval.
- Coin-Operated - If incentives and rewards are tied too explicitly to specific behaviors - as if you are training Pavlov's dogs, employees will optimize their work behavior to only spend time on maximally rewarding things at the expense of other important ones, and you can get into a death spiral of changing the weights of your incentives and rewards. You're better off having this stuff be a bit ambiguous and giving an entire group a bonus, than rewarding individuals and winding up with cutthroat behavior. For example, acquiring new customers is frequently less rewarding than selling into existing large customers, so it's common to see established sales organizations neglect customer acquisition.
- Management By Metric - Joel Spolsky writes well about this - whenever you create a metric people are measured on, you have created a way to game the system. Eventually it will be so well-gamed that that metric is very high and the organization is failing anyway. Ambiguity is your friend here, contrary to what a lot of business books teach - if someone knows exactly what needs to be done well, they know they only need to do those specific things well and will look for as narrow a definition of those things as they can get away with; if someone is not quite so clear on what needs to be done well, they must try to do everything well.