Company Culture Part II

I wanted to follow up my previous post on company culture with a questionnaire for job seekers and also some great quotes.

If I were to ask the right questions to a company interviewing me, I would start asking them about their culture:

  • Does your management team see developers as an asset or liability? Please explain.
  • How much time in a day would you allow for undisturbed, focused development?
  • What is your company’s purpose or goal? How do I share in that goal?
  • Do you allow your employees to maintain an online brand, blog or engage in social media during their personal time outside of business hours?
  • Do you allow your employees to moonlight, freelance, maintain their own online business, develop products/projects outside of business hours on personal equipment?

I believe it’s important for a developer to retain their creative rights outside of the company, even as a permanent developer. You should never sign a contract that gives your company exclusive rights to all your work outside of business hours.

I loved reading Valve’s employee handbook. For one, it starts with the company’s expectations, which is greatness. It begins with the following quote: “A fearless adventure in knowing what to do when no one’s there telling you what to do.” Great programmers are ones that execute and know what to do without asking anyone. I would love to work for a company where all of management understands this principle to empower the employee.

Some points on Valve’s culture are outlined below and to sum it all up, you get to ship products and work without being bossed around. What a phenomenal concept!

  • There is no hierarchy or organizational chart and they rely on self-managed teams. “Hierarchy is great for maintaining predictability and repeatability. It simplifies planning and makes it easier to control a large group of people from the top down, which is why military organizations rely on it so heavily.”…”telling them to sit at a desk and do what they’re told obliterates 99 percent of their value.”
  • Projects are self-initiated and self-directed. “We’ve heard that other companies have people allocate a percentage of their time to self-directed projects. At Valve, that percentage is 100.” It’s proven that when employees take time off to work on side-projects, actual innovation happens. Take 20% off your work week to be creative and come out with a new product.
  • Projects are volunteered for based on one’s own personal reflections and convictions about their own capabilities, interests and skills. “you’ll decide what to work on after asking yourself the right questions.”
  • Your are not boxed in with the total amount of value you can provide: “You were hired to constantly be looking around for the most valuable work you could be doing.”
  • “working overtime for extended periods indicates a fundamental failure in planning or communication. “
  • Failure has positive consequences, “Screwing up is a great way to find out that your assump tions were wrong or that your model of the world was a little bit off. As long as you update your model and move forward with a better picture, you’re doing it right. Look for ways to test your beliefs. Never be afraid to run an experiment or to collect more data…There are still some bad ways to fail. Repeating the same mistake over and over is one. “

Based on my own experience, most employees are under utilized, terribly managed, and not recognized. Instead of being crushed by useless meetings, ignorant managers, and delusional requirements, employees should have the power to be creative and have answers to the right questions such as “what’s the most valuable thing I can be working on? What’s interesting? What’s rewarding? What leverages my individual strengths the most?”

Advertisements

Company Culture is Critical to Success

What is culture? Culture is the combined set of VALUES, ATTITUDES and PHILOSOPHY that shape how you do things and why.

Does management view culture differently than developers? How do you improve culture? Most job seekers don’t ask about culture during an interview and most hiring managers don’t care . However, it’s been my experience that the reason why people quit is due to poor culture, a conflict of values. There is the Joel Test which indicated how companies value software development. However, there are also emotional and relational factors in culture.

I quit one of jobs because in three months time, I had to deal with three different managers. I quit the job prior to that one because my boss was an egotistical asshole. Fortunately, there are sites like GlassDoor.com that let you anonymously rate companies to blow off some steam. If you ever walk into work feeling depressed or anxious, it’s probably a time to quit. I want to work with a company that has great energy and treats their employees well.

You should know when it’s time to quit your job.

Below are true incidents poor culture among company associates. In my opinion, they are red flags and indicate conflict in values and philosophy.

  • When the president of the organization is invited for a brief demonstration of your product and their response is “I don’t care.”
  • When the president lines everyone up and says you’re all on thin ice. Does the president have any responsibility in why?
  • When the CFO is paranoid about the flu and walks in on everyones cubicle insisting they take flu shoots to prevent a decline in productivity. Since when is the CFO a health advisor? Ironically, everyone that got flu shots in my office got sick, except for me, since I ignore corporations telling me how to manage my health.
  • When the senior developer is mocking every phone interviewer for their lack of comprehension of technology but fails to act as a mentor to their own team.
  • When development is outsourced. This always doubles or triples cost of development since off-shore developers tend to miss-communicate and have poor understanding of design patterns and code architecture.
  • When it is a national holiday and management insists everyone come to work that day because they are behind. Why are they behind? Well, that’s management’s fault.

The Ideal Culture

I’ve realized that Europe treats their workers a lot better than America does. They take long beer breaks and vacations. The following rules would create the ideal software development company. They are based on the rule that you can do whatever you want, as long as you get the job done. I’ve actually seen some companies that provide some of these perks. It would be great if more companies would adopt them.

  • Come to work whenever you want and leave whenever you want. On an average day, I may come to work at 10AM and leave at 7PM. If I enjoy working later, during the evening, I may take a few hours off and relax with a massage and work till midnight. It’s proven that developers work better at night.
  • Take long breaks. Employees can go to the gymn, relax at the lounge, go for a swim at the beach. This helps improve happiness, creativity and reduces fatigue. Employers should provide local discounts to employees and grant them access to workout, relax and meditate during production hours.
  • Have a standing desk. Programmers should not have to sit down for long periods. This is a health hazard.
  • Have access to an excellent tea and coffee machine.
  • Have opportunities to innovate, try new ideas, branch off on a project and get paid for it.

I hope more American companies will adopt a great culture. Hopefully more employees will push for this change. However, If you can’t change your company, then you can always change your company.

Documentation As Your Legacy

Based on hearsay, developers hate documentation…until they come across a project with no documentation!

As you leave your company, how do you want to be remembered? Let me put it this way, if the next programmer is a serial killer that has to review legacy code that you wrote, would you want him to know where you live? Once I thought following a zero comment policy as good because classes, methods, variables should be human readable and obvious, however, there will always be someone who complains about the lack of comments and that your documentation is overwhelming. So, comment sparingly, but when you comment, complement the existing code and comment specifically business reasons behind your code. It’s also useful to use tools in your IDE that automatically apply comments to properties and classes. This is important, but if you comment every object, please don’t leave the default auto-generated comments in there, as they are just as useless as no comments. Finally, you should always reference your code classes to the user-friendly documentation in some other system (such as Confluence). If you comment your code where appropriate and also provide documentation for all your code, then you will be appreciated long past your stay.