In one word: culture.

I recently had a vacation and it gave me some time to reflect on what I find is important to me as a technologist. I’ve narrowed it down to two main categories however when i think about the overarching picture only one thing stood out to me. Interestingly as I thought my way through this, specific technologies or languages never seemed to surface. All the proper nouns that you see on a job description (i.e. Java, C#, Spring, Linux, etc.) on a resume, well they don’t matter really matter to me that much. Even as I look through a lens of software development they only matter in a seemingly way. That’s simply not what I’m interested in as a potential candidate or an interviewer. Let me explain what I mean.

Culture in the Team

The Daily Bullshit Contest

When I say bullshit I don’t mean that to be necessarily negative, I just can’t think of a better word that will stick in your mind as I try to describe this to you. This is the conversations you have with the other devs, qa, and “whoseits” and “whatsoes.“ Stories about how your stupid dog at a hole through a wall, or when you were mowing the yard and were attacked by a hornets nest. These conversations are not apparently productive for your project, but it is a sign of a healthy team. This demonstrates that the team is not afraid to talk to each other. Of course this doesn’t mean that Johnny will ask for help when he’s stuck (maybe he’s proud, maybe he’s reluctant to look stupid in front of his peers). It’s bullshit like this though that help people become more comfortable with one another and it’s a subtle thing that’s very important.

Drive to learn and share

The amount of things to learn in technology is beyond my comprehension. Certain techs and libraries are more suitable for certain domains and there’s no true “one way to code it all.” When a team of motivated individuals is spending personal time working on pet projects or learning new tech, the entire team can benefit from it even if that new JavaScript library isn’t adopted. It can inspire developers to try something new and influence them to attack tomorrow’s problems differently. The team as a whole is better equipped to deliver value and quality to the business from being able to share their experiences regularly.

Team lunch/outings

Similarly to the Daily Bullshit Contest, a team that wants to spend time together is a sign that things are going to be alright for you in you new project. We spend more time with our co-workers than we do with our families and seeing your team want to grab lunch together or grab a beer after (during) work shows that the team is durable. If a PM throws a clusterf**k of a project at them they can more likely sort their way through it. Without that level of collaboration and trust that project may look a lot more grim.

Culture in the Workplace

Sharing experiences with non-developer/non-tech folks

Developing the culture of developer folks and non-developer folks is extremely important to the success of a project, especially if the software is being built for your in house customer bt it also applies to when software is the product your company is selling. It’s difficult for business users to articulate what they want. This can be because they don’t know what’s possible, don’t realize what they know developers may not, or they know they want something “better” but don’t know what that would be. Developers are equally at fault when making assumptions about business rules, not taking the initiative to do the analysis into the business process, or blaming the business for not giving them the requirements when they themselves cannot define what that even means. Building a piece of software is not following a blueprint and ending up with the Taj Mahal. It takes a lot of effort and hard conversations to get it right. A big trend in the industry is assuming project management frameworks like Scrum will keep developers from having to essentially redo work when it doesn’t meet the needs of the business. Scrum doesn’t solve that problem. Sure it provides a mechanic in will those feedback loops are tighter but you still are running the risk of developing the wrong thing. Having a team that’s tightly integrated where the business user is essentially sitting at the developer’s desk will actually help keep the project on time and on budget. Of course the big hurdle with that is convincing management to allow a business user to devote that kind of time to something. If the collectives team culture is strong this will begin to happen organically over time because not only will they want to do this but they will be able to articulate to management the importance and show the effectiveness with this level of collaboration.

Celebrating wins

Projects can become grueling behemoths and will wear people out and tear them down, especially if deadlines begin to slip or push back. Keeping the team focused on the progress they’ve made is a must. Showing them (not telling them) how far they’ve come can be a huge motivator and can propel the project forward meaning you’re freeing up resources faster for the next big thing and delivering more value to the business. Having a small party and throwing back a couple beer can really do wonders to your project. Just don’t introduce those dumb icebreaker sessions. In my experience they are mostly awkward and boring, let the ice break naturally which will take more time perhaps but it will be a stronger bonding experience for everyone involved.

##Celebrating personal or team achievements

Be sure to celebrate the achievements of individuals or teams but before you parade them in front of the group ask that person if they are comfortable being called out in public. I for one do not want to be put on display, but I do appreciate it when individuals congratulate me for not screwing up. Congratulating people will increase their confidence and make the team stronger for it. Depending on your team and what you’re doing introducing gamification or “achievements” could be a motivator for some (though it may be too much overhead or become a distraction from the goal). Also those personal achievement could inspire others to further pursue their goals. These personal achievements could be anything from becoming a Microsoft MVP, finishing a 5k, or surviving a visit from the in-laws. Ultimately you want the individuals on your team to feel included, important, and invested in your project. All of this promotes an environment where individuals feel appreciated, valued, comfortable, and confident. Furthermore, it’s an environment where these individuals feel like they are part of a bigger whole and everyone is working toward a common goal.

Culture is invaluable to the success of your project and your company. Let’s be clear, you can’t buy culture. Pool tables are not part of the culture. Buying a keg of beer is not creating the culture. Culture is created through the interactions and experiences of the team. Sure you can buy some pool tables or a keg of beer to help facilitate the mingling of your team but unless get to know each other your organization is heading for dire straights.