Skip to main content

Fear, Control, Safety, and Trust

After having been in the software industry for over 17 years now, I've seen many approaches to running software projects. I've worked in companies that had just under 20 people, to large corporations that employed several thousand. The projects have included products that are used by millions of people, to internal software that was highly regulated. Despite all of that variation, I can pretty much break down all of the projects in two categories; projects that are run via command and control and projects that are run with collaboration and trust.

One might assume that the projects run via control are always at large corporations, or from more regulated industries. But in my experience that isn't necessarily the case. The biggest company that I worked for was also perhaps one of the most progressive in terms of practices, while some of the smaller companies were just the opposite. Perhaps not coincidentally the largest and most progressive company was also the most successful.

Today we live in an agile software development world. That is to say that almost all software projects are run with agile in mind. Despite that, many leaders miss the meaning behind agile and instead focus on processes and tools. To be clear having "stand-ups" and user stories doesn't make a project agile. Ultimately it comes down to a mindset and culture. The mindset that the team as a whole has the best interested of the system at heart, and if they are given the freedom and flexibility, they will help create a better product.

It pains me this to day to continually seeing "agile" projects run from a central authority that focuses on control. By creating this type of environment, ultimately they are suppressing the output of the team. From my experience the leaders that want to control are ultimately coming from a place of fear. Often they simply don't trust their team members to make the right decisions. To me it seems quite odd to hire someone, only to tell them how exactly to do something.

While this isn't anything new, it does bear repeating; for best results leaders should create an open environment where everyone feels safe to share and discuss ideas. If you don't believe that's the right way to run a project, then perhaps you need to take a look in the mirror and ask yourself why you have a team at all if you can't trust them to get the job done.

This reminds me of first time being a technical lead for a group of developers. I was a little bit nervous as being a leader was new to me and I wanted to get it right. I had some extremely bright and skilled software developers working on the team. At one point the thought crossed my mind "This guy is better technically than me ... is he going to make me look bad?" But instead of acting defensively based on that initial fear, I realized that we were all a team. We were going to get the most out of the team by allowing everyone to shine and be at their best. By setting aside egos, we all worked together and were able to share the eventual success that came. It was one of the best experiences I've had with a group, because we were all in it together and there was safety amongst the members of the group. This is just one example; I've worked in several teams like this all with good results.

Unfortunately I haven't always had positive experiences. In particular in groups where control was the norm, you often had people acting selfishly, often hiding information from other teammates and essentially people were working against each other. Needless to say that isn't a fun experience, and the quality of the software suffered tremendously. Sometimes I wonder how some of those organizations manage to stay in business. Mind you not all groups that are run via control have that behavior, but I haven't seen that behavior in teams that are given the freedom to manage themselves.

Finally, I'd like to add a word of caution. It takes time to build trust. It's also much easier to build trust with your peers. Over the years I've found myself speaking open and candidly with others, more so after working in cultures where open communication was the norm. Unfortunately, depending on an organization's culture, this candor can be taken the wrong way. Even if you think you have a good working relationship with someone, you have to be careful when you open up because they might not be ready for it. Simply put some people see it as a threat, and it can't trigger very negative reactions. This can especially can be the case when the people you are talking to are not peers but rather are higher up on the food chain.

If you're a leader, create an environment that fosters collaboration. We should all feel some level of safety and trust in the work place. If there's someone that for whatever reason goes against that grain, try to bring them into the fold. If they continue to resist, then perhaps they are not the type of person that you want on your team. Most importantly, as a team set your ego aside and do what's best for the group. It might be hard if you're used to working in a cut throat environment, but in the long term you're only hurting yourself. You may think you're protecting yourself, but it only leads to resentment and conflict. Even in scenarios where you have a difficult team member, I've found the best way to handle it is to be inclusive and let them share in the success.


Popular posts from this blog

Value and Quality over Schedules

According to a study by CEB Research, 70% of software projects are delivered on time, but only on 38% meet stakeholder's expectations. In most cases the people that use your software will not even be aware of internal project deadlines. Case in point, think of all of the software the you use everyday. You are rarely aware of what the due date was. However, what you do notice is how well the software does it's job. It's it's of low quality, you'll very likely notice right away. Even if it appears to be of high quality, if it doesn't provide any major value to you, chances are you still stop using it. With that in mind, then why do many software projects today have a set scope and a hard due date? When building software for a customer, it's only natural for them to what to know what exactly they are going to get and what is will cost them. That is a very reasonable thing to want to know. Even when developing software internally, there are often similar expe

Let's Get Moving With Software Development!

Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours. Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantl

The Cost of Meetings

Meetings ... love them or hate them they are a part of everyday business life. I've had multiple bosses that detested meetings, saw them as a waste of time, and would dissuade us from having them. On the other end of the spectrum I've worked for organizations that had countless meeting, many that were of little relevance to me, and left little time in the day to accomplish my other duties. In this posting I aim to examine the cost and benefits of meetings, and also touch upon what it takes to have effective meetings. As someone that has worked as a software developer, team leader, and manager of developers over the years, I'd like to think that I've seen the good and bad side of meetings. Let's start first with the cost. Everyone would agree that a 1 hour meeting requires at least an hours worth of time for everyone that attends. Add to that the need to break ones focus from what they were doing, and regaining that focus after the meeting, you may even raise that