[ Content | View menu ]

Culture, Work Location and Critical Thinking

Mark Mzyk February 24, 2013

Recently I read Shanely’s What Your Culture Really Says. I’v also been seeing a lot of tweets about how you should let employees work remotely lately. Certainly DHH has been saying this loudly for a long time.

There is a truth in these arguments, but they go too far. Life is complicated and there is no one right way. You should see what everyone is saying, think about it, and then incorporate those elements that work for you and make your culture better.

Working Remotely

Let’s look at working remotely. It’s true that working remotely can be great. I work remotely. It would be difficult for me to to go back to working from an office. It allows flexibility for the worker who gets to work from home and it allows flexibility for the employeer, who gets to hire regardless of location. That doesn’t mean it’s always great for everyone.

If you’re an employeer you have to consider the tax and law implications of hiring someone from another state or even another country. Is your business ready to take on these complications?  Beyond the legal aspect, there are other issues with remote work. The employee has to know that they can handle working remotely. When your office is your laptop, you can work anytime, anywhere. This is a blessing and a curse. If you work in an office, when you leave your work is often done for the day. You can focus on family because the temptation of work is an office away, instead of a laptop away. There is a clean separation between home life and work. Some employees need this, but it can be difficult to know if you’re someone who does until you try working remote.

Supporting remote workers also takes the right office culture. Even those workers who work from the office need to shift their behavior as if they were a remote worker. Conversations and decisions need to move online so that remote workers are included and understand what is happening. If this doesn’t happen, its easy for the remote worker to feel left out and for productivity to drop as they try to find the information they need. If decisions at your company are decided in hallway conversations, having remote employees isn’t going to be successful.

Face to face communication is still the best way to communicate. Despite the fact that online tools have come a long way, being in a room with someone is the best way to get to know them and communicate effectively. Even when working remote, it’s much easier if at some point you’ve had face to face communication with the other people you are working with. This builds rapport so that remote employees can understand the meaning and intent behind communication from their coworkers. What most companies with remote workers don’t often publicize is that periodically all the remote workers gather at the company headquarters or get together somewhere in person to build a rapport. If you’re going to have remote workers, be prepared to do this at least once a year, if not more often.

Is working remote great? Absolutely. It gives the remote worker flexibility in their schedule and where they live. It gives the company an expanded talent pool to draw from. Ultimately you need to think about the changes it takes to support remote workers and if your company is capable and willing to make them for the benefits that come with remote workers.

Company Culture

Much like there are caveats to remote working, there are caveats to any culture you might adapt. To pull one example from Shanely’s post, let’s look at a culture of having no managers. What Shanely says could certainly be true, but I also believe it doesn’t have to be. I assume the reference she is making is to GitHub, as they have been the company most vocal about having no managers.

I’ve been watching GitHub for a long time, like most people in the tech world. They are an amazing story. Recently they cleared 150 employees. I take them at their word that they have no managers. I also don’t think this is a strategy that is going to work for most companies. Why? Because most companies don’t have the same hiring practices GitHub does. For a long time, GitHub has been hiring very senior people. Their employees usually join the company with years of work under their belt and have proven themselves to be leaders in whatever their chosen specialty is. These are very self driven people who know how to get things done and how to organize to do it. If every company had employees like this then no company would need managers either. It is much harder to be a company of no managers when you’ve taken young or unskilled employees on. These employees need guidance and direction, or else they have a tendency to bounce from one shiny tech to the next. That guidance usually comes in the form of a manager.

There is also the fact that GitHub has been profitable for a long time and now has massive cash on hand after their funding from Andreessen Horowitz. When money isn’t an issue that frees up everyone in a company. If someone goes off on a side project that doesn’t add to the bottom line now, but might in the future, well, that’s okay, because the bottom line right now is just fine. GitHub has this freedom, most other companies don’t.

The Takeaway

What is the takeaway here? To be cliche, it’s that things are complicated. There are good things in the reports that come out about company culture and working remotely, but it’s up to you to look at them with a critical eye. Think about why it works for the company saying it. Think about what they might not be saying. Then take what works for you and improve your company culture.

 

Culture - 0 Comments


Viewing Chef Node Attributes with Knife

Mark Mzyk February 5, 2013

This is a simple post to list all the ways you can view Chef node attributes with knife, even nested attributes, which is harder than it feels like it should be.

A lot of this information can be found at docs.opscode.com, but as of this writing the examples for knife node show don’t always go into enough detail.

knife raw was a part of the knife-essentials gem but as of Chef 11 has been integrated into standard knife. If you aren’t running Chef 11, you can install the knife-essentials gem.

 

Show basic info about the node, truncated and nicely formated:

knife node show <node_name>

Show all the information about a node, nicely formated:

knife node show -l <node_name>

 

Three ways to list node information, in the raw json form (note the -l or –long option is needed to return all node data for knife node show so that all node attribute data is included)

knife node show -l -F json <node_name>

knife node show -l --format=json <node_name>

knife raw /nodes/<node_name>

 

How to list a single node attribute:

knife node show <node_name> -a <attribute_name>

attribute_name will be something like kernel or platform.

 

However, this doesn’t work for nested attributes, such as node[kernel][machine], as knife node show doesn’t understand nested attributes.

 

If you don’t want to use the raw json and grep, you can find a nested attribute by doing a search:

knife search node <query_to_run> -a <main_attribute>.<nested_attribute>

An example:

knife search node name:<node_name> -a kernel.machine

 

Hopefully this is useful information to others. Information on using search to find nested attributes was originally found on this log of the #chef irc channel.

Tools - 2 Comments


Giving Up Childish Ways

Mark Mzyk January 22, 2013

“When I was a child, I spoke like a child, thought like a child, and reasoned like a child. When I became a man, I gave up my childish ways.”

1 Corinthians, 13:11

As I read Mathias Meyer’s latest post, Failure is Always an Option, I was struck by how he began. He gives two examples of failure, one from the airline industry and one from the steel industry, before then moving onto their lessons and how they can be applied to the software industry.

This caused me to start thinking how DevOps fits into the larger picture of software development and even within the context of other industries. I realized that what Mathias is writing about in his post, and what DevOps is an indication of, is the software industry maturing. Industries like the airline and steel industries are very mature industries, while the software industry is barely out of infancy. The airline and steel industries understand failure, while the software industry is still learning how to handle failure in a mature way.

There are many parts to growing up. When a person grows up we see changes in the way they look. They usually grow taller, their features change to become less childlike. We might notice they change the way they dress or they buy nicer things. Society comes to recognize they can buy alcohol or vote. Yet even when a person has done all these things, we might still call them a child, because we recognize that while they look like and can take the actions of an adult, in their behavior they are still a child.

While the software industry might look like an adult, we can see in its actions that it is still a very immature industry. However, it is maturing in fits and starts. We see this in the agile and devops movements. These movements are cultural movements, behavioral movements. They lay out the practices that adults follow. Of course, companies will adopt and practice them in different ways, just as all children don’t grow up to become the same adult. It isn’t the developer’s or sysadmin’s place to put down a company when they see the company doing agile or devops differently than they would. It is a sign of a mature developer or sysadmin who can see something they disagree with and work in a positive manner to bring about change, or who opts to model the better behavior and lead by their actions.

“Through this work we have come to value: Individuals and interactions over processes and tools”

Agile Manifesto

This is a declaration of growing up. It says I am an adult; I understand how to act and don’t need someone else to lay out rules for me. DevOps follows in this, in that DevOps says that developers and sysadmins are adults and respect each other. Through mutual respect they work together, knowing that their faults and failures will be laid bare, but that this is in fact the behavior they want, because it means everyone can learn and become better.

While agile and DevOps may have practices spring up that some say you have to follow to be truly agile or truly DevOps, the mature engineer knows that these are tools to help the less mature grow. If you use them or not, it doesn’t matter, so long as you act like an adult. Some adults wear suits to work, others wear cargo shorts. These things are only for appearance. What matters is how you act.

We’ll know the software industry has grown up when it becomes common practice to treat failure seriously and embrace it, instead of treat it as a shame to be hidden. As others have pointed out, we can learn a lot from other disciplines.

It’s time to give up our childish ways.

Software Engineering - 0 Comments