Upon reflection, my dream workplace culture would have following properties, listed below in no particular order:
- Employees are encouraged to use any system/config/setup that they want
- Nobody ever has set work hours
- Nobody ever has any set work place
- Every employee is salaried
- Any meeting lasting longer than 15 min must be scheduled at least a day in advance
- If a meeting follows the pub/sub model, it should be an email instead of a meeting
- All development happens in the open
- Every employee has 1 day per week to work on anything that they want
- Each employee must respond to at least one support case per week (if that many cases exist)
- Every employee has the responsibility to be at least somewhat familiar with the company strategy and product roadmap(s) at at least a high level
- Every employee has the right to be a part of the decision making process perternaing to the company/product vision/roadmap(s)
- The only information that an employee is not privy to is their coworkers’ salaries
Explanations
Employees are encouraged to use any system/config/setup that they want
Here I mean that I want every employee to constantly be tweaking their work environment to make them "better" at their job – whatever that job may be. For developers, this culture property probably means that they are encouraged to use any text editor, web browser, development tool, or operating system that they so choose. With regard to non-developer employees, this point probably means that they are encouraged to use whatever email client, software, phone, etc. is going to make them better.
The main point is that I want all employees to be enabled to constantly evaluate how they are doing their job and try to optimize their performance for whatever metric makes sense based on their role.
Nobody ever has set work hours
What I mean here is that I recognize that people have different schedules and different times at which they are most productive. Personally, I am most productive from 05:00 – 11:00 and then from about 18:00 – 20:30; For other people, this schedule is when they are least productive. The main point is that I want employees to be able to work when they are going to be most productive and not feel like they must work from 09:00 to 17:00.
Nobody ever has any set work place
The point here is very similar to point 2 above – I recognize that there are times when working in solitude at home is going to make a person the most productive and there are times when working from a coffee shop is going to be the most beneficial. There are also times when being in an office next to your coworker is going to be the best place to really crank out some work. I want the company to recognize and encourage all employees to be proactive about choosing the place that is going to be the best for them to work in. Personally, I happen to love hacking on code sitting outside on the grass in the sunshine.
Every employee is salaried
I don’t ever want an employee to think, "it is 17:00, time to head home and quit thinking about this problem." nor do I ever want any employee to work longer just to make more money while being less efficient. I think that salaries encourage people to be productive however they personally can. Also, with wanting point 2 where no employee has set working hours, paying an hourly wage would require massive amounts of paperwork and process.
Any meeting lasting longer than 15 minutes must be scheduled at least a day in advance
This is partly a corollary of points 2 and 3, and partly a standalone point. With every employee working whenever and wherever they are going to be the most productive, meetings that require synchronicity must be scheduled in advance. Additionally, some people (myself included) like to run through a mental plan of how their next few days are going to go, and being knowledgeable of all the requirements on my time is essential for that process.
If a meeting follows the pub/sub model, it should be an email instead of a meeting
There is nothing worse than a meeting in which one person is just pumping information out to the rest of the attendees with no needed response. I call this the pub/sub meeting model – as in the publishing/subscribing model for syndication and event handling. These kinds of meeting are a huge drag on people’s attention, energy, focus, everything, and are better suited by the speaker sending the information in an email. Meetings are only necessary when discussion is required.
All development happens in the open
This point may only apply to developers and their ilk, but I think that it is very important that developers be allowed to see, and contribute to any code that the company uses. This allows (potentially) more eyes to review code, and it allows developers to take a brief diversion and work on something possibly entirely different than they normally would. The advantages to this are at least twofold; This helps prevent developers getting bored with their work, and it encourages developers to always be learning new things instead of having their skill set stagnate.
Every employee has 1 day per week to work on anything that they want
A corollary to point 7, is that every employee has 1 day per week in which they are encouraged to work on anything that they so desire. This side project could be related to their job, or it could be practicing basket weaving. The rationale for this point is the same as the rationale for point 7 – preventing boredom and skillset stagnation.
Each employee must respond to at least one support case per week (if that many cases exist)
I think that is important for every employee to realize what the end users’ pain points are in the products. Having this information readily available makes it easier for employees to make executive decisions and make the products more user-friendly. It is also always extremely eye-opening to see how exactly customers are using what you made. Often times it seems like customers always find a cool way to abuse the product into working in some unintended manner.
Every employee has the responsibility to be at least somewhat familiar with the company strategy and product roadmap(s) at at least a high level
This builds on point 9 above, if every employee is empowered to make the products better, they should know where the company has decided to make the product end up.
Every employee has the right to be a part of the decision making process pertaining to the company/product vision/roadmap(s)
Since employees are required to have a rough idea of the company vision and product roadmap(s), they should also have input into what those visions are. Employees also have firsthand knowledge of how customers are using, and how customers are abusing, the products because they are seeing support cases come in. This knowledge is information that is required in the product planning process.
The only information that an employee is not privy to is their coworkers’ salaries
Based on all the points above, employees are going to have a high degree of knowledge about the company. Employees are also going to be used to being able to improve any aspect of the company, which has a prerequisite of knowledge. That knowledge should be made available to all employees. It would be incredibly heartening to see real data on the company when things are going well and really eye-opening to see that same data in a downturn. That being so, the only information that an employee should be able to see is what their coworkers’ salaries are. While this information would be interesting, knowledge of it would create a heirarchy which might work to stop employees from being as proactive as they otherwise would be. Employees may start thinking, “that person makes more than me, so their input must be more valuable” which is false thinking and will lead to demoralization.
Drawbacks
There are probably some definite drawbacks to these points. I can see that some people might not see the value in paying employees to spend one day a week working on something that may have no direct benefit to the company. I can see how in a very large organization, point 11 might result in a "too many chiefs, not enough indians" kind of situation. I can see that points 2 and 3, under which no employee has set hours or location to work in, might result in inefficiencies.
I think that the first drawback of paid side project time is sufficiently addressed in the rationale for that point above. As for how to avoid the "too many chiefs, not enough indians" situation, I am not sure of a solution. Assuredly, not every employee is going to want to be a part of every decision-making process, so maybe this situation is self-fixing. As for employees who have no set work hours or place becoming lazy and inefficient, I think that the proper solution is to be clear from the onset that any employee who routinely fails to meet the expectations of them will be let go. This has the effect of ensuring that employees who can keep themselves on task, and are proactive about self-improvement remain and thrive, while those that cannot are not a drain on company resources.
Conclusion
When I had my wife proofread this, she asked me "So are you unhappy with where you work?". The answer to that is a resounding "no!". I rather enjoy my current job and the culture there has a majority of my points in it. Would I quit this current awesome job to work somewhere that has all of my points as part of its culture? The answer is that I don’t know, and it would require some thinking. When I have my own company someday, or am a very early employee at a company again, am I going to try and get these points to be part of the culture there? Of course I am going to.
I am of the firm belief that while I may get paid in exchange for slinging code around, it is always my responsibility to improve how I and my coworkers do that slinging.