Building a positive environment for building software

by

Lets start with why a positive environment for building the software matters. Prior posts explain that that the core business is everything other than the software, and the software is just a tool, but that should not diminish the importance put upon building a team who loves making that tool the best it can be.

A positive environment is good for all stakeholders in the software development process - members of the various product and engineering teams will enjoy their work and be satisfied making it a part of their life. The business in turn has a team they can rely on to fulfill the sustainability needs of the organization.

So what is needed to build a positive environment?

In short, you need to build a working environment that matches the personality of your team. In the software world, the teams tend to be comprised of members who are above average in intelligence, have a desire to be engaged with their work, and have a desire to create something new as a result of their work. They tend to want autonomy in their day-to-day work, to be trusted, and to be given a level of responsibility that matches their skills, as well as opportunity to grow their level of skills and be rewarded with increased responsibility, autonomy, and trust.

This is not the same as non-software environments. There are styles of leadership that work in other industries that will fail in software. Autocratic leadership is the one style that will fail almost 100% of the time. Servant leadership works for first line managers. Higher levels of management need to be focused on delegation, direction, and alignment.

My focus is on the product-focused areas of an organization. This includes:

  • Engineers whose responsibility encompasses the coding and architecture of the product itself
  • Operational staff who keep the systems up and running
  • Support staff who communicate with the customers
  • Product management staff who research the market and decide what the product needs to do
  • Design staff responsibilie for how the customers and other stakeholder interact with the product.
  • QA staff who test the product and identify problems before changes are sent to the customers.
  • Leadership who keeps all those people in alignment.

Note the exclusions from this list:

  • Executive leadership
  • Sales and Marketing
  • HR, accounting, and other internal corporate functions

I call out those exclusions because their satisfaction with their work environment is often not correlated with the satisfaction of the product team. I’ve seen happy product teams build amazing successful products even when other areas of the organization are miserable. Likewise, I’ve seen products fail when everyone else is happy, but the product team is miserable.

So do you keep those teams happy?

This is no single answer to this. As much as there will be similarities between people who gravitate to software work, we are all different people. The number one priority when determining how to structure your product team and all its processes, communications, and other aspects of its culture is simply to listen. Ask the team how they want to work. Let them work how they want. Let them experiment and self-govern to find their best working environments. Remove people from the team who are blockers to improving the health of the team. Hire people into the team who will fit the team culture they have built. Basically, let them work their way, not yours.

Even so, organizational leaders can put guardrails and requirements on the team. You can define what information you need to hear back from the team in order to understand their progress. You can give them the high-level goals that need to be accomplished. You can express the needs of the business to them. But it should be your goal to give them such requirements at as high of a level as possible, then trust them to handle the details. Your customers don’t care how the sausage is made, and really… neither should you.

At least, in theory. In reality, you do need to know where the team landed on their own organization. Ideally, a senior leader lets the team make decisions that align with the needs that have been communicated, then simply confirm their direction. But sometimes you need to referee. Sometimes business needs force specific internal processes. (Security needs, regulatory needs, etc.)

All that being said, there a few universal truths about a positive software culture:

  • Do not rush the team. Some teams are fast, some are not, but if you push them faster than their natural pace, the quality of the product will suffer. Trust your team to know when to take shortcuts, when to put in time, when to make up for past shortcuts.
  • Everybody has an opinion about remote work. Build a team who agrees on whether or not they want to be in-person vs. remote. Mixing the two doesn’t work. This choice will exclude specific people from being on the team. Consider that a good thing - there is enough talent in this industry to go around, so if your otherwise perfect team member doesn’t want to match the rest of the team, that is a deal-killer. Hire people who match.
  • Do not micro-manage. Software people are rarely, if ever, the type of person who wants that.