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.
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.
Comments