Making Cultural Shift Happen
Let me paint a picture and see if it sounds familiar to you:
You’re two weeks past the delivery date of the project you’ve been assigned to. So far, you’ve heard around the watercooler talk of staging yet another “coup” because your fellow developers feel that management has once again “dropped the ball” by letting the offshore team take the lead on the project without even consulting the in-house team.
Even more are saying that that the development group as a whole is a disorganized mess. Overtime, you have noticed a large emphasis on process, with days filled with meetings, fiefdoms of knowledge existing, and a general lack of decisiveness on issues which have arisen. All of this combined, gives the team an impression of impending doom.
As you look around at the downtrodden faces of your fellow developers, you know that they are smart, capable and talented people, yet they just aren’t given the challenge of developing anything.
Does that sound like something you’ve experienced?
Throughout my software development career, I have had the opportunity to work with a broad variety of development shops. Some are like what I just described, and aren’t exactly ideal. But some just seem to ‘have it together,’ where it was truly a tough decision to leave such an optimal environment. (The good and the bad of consulting – for better or for worse, you move on to the next project!)
If your dev shop is like the one I described above, and you want to move in a direction where
- the department is cutting edge.
- the department can innovate and execute projects.
- roadblocks and impediments are not self created.
Then a magic wand correction for this would be a sweeping cultural change of the department. From the bottom to the top, your development group must make a huge cultural shift.
What’s the key to cultural shift? It’s a combination of factors, and a vast majority of them have to come from the management team. The three I will talk about include the empowerment of your people, educational opportunities, and in-house project engagement.
1. The Red Tape Has To Go
Bottom line, you must empower your developers. I have often seen dev shops that layer multiple processes upon their teams (Saying you’re agile does not make one agile, after all!) and having them need to justify their actions according to the process, which only creates more process. Process for the sake of having a process, and your developers are held back with red tape from focusing on their strengths.
Senior management has the ability to give incredible latitude for the team members to not only innovate, but to execute those decisions on their own. You have hired professionals to create amazing things, I encourage you to give them the ability to to do just that.
If your development group is like the one I described above, then I honestly believe that many in the department would want a change. (I would.)
2. Focus on Education
Another piece of the transition is giving the team the education to be successful, and providing the opportunity for advanced collaboration. If you don’t have senior-level individuals for your team to learn from, bring in a team of consultants who have the experience and/or the expertise to teach, guide, and mentor your own in-house teams for future success. Utilize those people to the fullest extent.
This is a very different approach than the “bad culture” picture described above. In that scenario, one group would likely be siloed off, separating consultants from the employees, and regulating one group to work on months-old bugs or legacy code.
When siloing specific groups, you miss an opportunity to enhance your teams. Use senior level individuals to raise the skill levels of your in-house people, to increase your developers knowledge and skills and to drive forth the changes.
3. Don’t Leave In-House Teams Out of the Fun
Even speaking from a consultant’s perspective, outsourcing every major project to third parties has to stop. Your team members, the individuals you interviewed, hired, and committed to, have spent hundreds of hours learning their craft. When you leave them out of the latest and greatest projects, they are now a backup crew for an offshore development team. They need to be your first string. Empowerment and education!
Plus, if your relationship with a third-party ends, it’s your in-house teams that must maintain the application that was built. What will happen if they had no involvement in it before, and it’s just thrown in their lap? Lost revenue.
Consider this: if every exciting new project goes to outside developers, what is the motivation for good in-house developers to continue honing their craft? To keep them engaged and knowledgeable on the latest and greatest technology trends? There is none, and the culture suffers. Let your people create a new breed of products!
Even if your culture sucks now, there is still great potential. I encourage you to empower your employees, challenge them, include them, and provide with the education (both internal and external) that they need to keep your dev shop ahead.
The winning key is that a cultural shift has to come from senior leadership. Full adoption. Don’t wait!
|Reference:||Making Cultural Shift Happen from our WCG partner Keyhole Software at the Keyhole Software blog.|