When a Company Culture (Actually) Supports Its Developers
If software products are your core business, growing such a culture isn't optional; it's crucial for the existence of your organization!
by
Join the DZone community and get the full member experience.
Join For Free
For years, I've fulfilled the role of Scrum Master for many different organizations and Scrum Teams. These teams were mostly focused on software development. I've been in the fortunate position of having worked for some great organizations. These organizations were able to attract the smartest developers and create products customers loved. Everyone enjoyed going to work and looked forward to learning new stuff, helping each other solve tough problems, and engage with the users of the product.
You may also like: Self-Organizing, Self-Directing, Self-Managing, and Authority
But I've also worked for organizations where people struggled to create such a culture. For them, it was difficult to keep the high potential developers on board and hire new ones. Often, after only having worked shortly for such an organization, I already felt what the problem was: They lacked a "Developer Culture."
In the beginning, it was only the smell of the place that made me conclude this. Over time, however, more tangible examples popped up.
Everyone agreed on how serious this was. The organization was full of people discussing "what" needed to be built; the problem was that there weren't any people that could actually build the product.
For these organizations, creating a Developer Culture isn't a nice to have; it's the only way to survive!
In this blog post, I'll share examples of how I experienced a Developer Culture. Now, what I don't want to do is write a vague article about culture full of fluffiness that might sound interesting but doesn't provide any clarity. I'm simply going to share my perspective as a Scrum Master working closely with developers. That's not going to be a technical perspective; while I did try being a developer, I failed miserably...
So, to be clear, whenever I write "developer" in this article, I mean everyone involved in writing software and building products. This can be a developer, analyst, tester, designer, architect, etc.
Examples that I've experienced and consider part of a Developer Culture are:
Development Teams are considered the most important part of the organization.
Everyone that's not part of the Development Team is there to support them, not the other way around. HR, Finance, Sales, and Management should be focused on making the life of developers as convenient as possible. Don't let Development Teams get lost and stuck in the organization's hierarchy.
Developers are paid really well.
I've always considered it strange that in organizations where everyone agreed that developers were crucial for the organization's very existence, developers were nevertheless paid poorly (compared with others in the organization).
If you truly consider developers that important, put your money where your mouth is.
It seems, however, that whenever the work being done becomes more tangible, the salary decreases. Wherever the work becomes vaguer, it's the other way around.
It's about the outcome, not output.
It's about building valuable software for the customer, using the least amount of time, not about finishing as many tasks as possible, of which the value isn't clear. Also, involve the Development Team in determining the value. This will help them build the right things, and build it right.
Development Teams choose their own metrics to measure progress.
These metrics are focused on the outcome. Examples are cycle time, customer satisfaction, team happiness, innovation rate, return on investment, and total defects. Avoid metrics that focus on utilization and efficiency. They encourage local optimization, are easy to manipulate, and are often used to control individuals.
Everyone is in contact with the customer.
The real customer, not (only) stakeholders that know a customer. I mean the person using the product. If this means that developers need to leave the office to visit a customer, awesome!
I've once hired a mini-van and took the entire team to a customer. This proved to be a nice team-building activity as well.
They can choose and purchase their own gear.
With gear, I mean screens, desks, chairs, headsets, etc. I've experienced organizations where developers were doing multi-million projects, but having two screens or a decent headset "wasn't possible." This was against company policies. The result: unhappy developers that try to sneak in their own gear from home. This created a culture of fear, secrets, and fighting "the system." I can't imagine this is the culture organizations want to have.
A budget is provided for having some fun.
How and when they spend it, well, that's up to them! It might be visiting an escape room, organizing a LAN-party, having a BBQ, playing paintball, or going on a boat trip, as long as it helps them gel as a team. Nothing beats a good team activity!
A suitable environment is offered in which they can do complex work.
Many organizations still use "flex-desks" and " open-office space" where everyone is sitting together. For developers, this is often a nightmare.
Lack of focus, no feeling of having a team space, and continuously being distracted doesn't help with solving complex problems or doing innovative work. If they want, give them their own team room. Let them decorate the room however they want. Provide whiteboards. Lots of whiteboards. If a team room isn't possible or necessary, simply involve them in creating their own environment in which they feel comfortable.
Development Teams take responsibility for hiring new team members.
In The Netherlands, everyone knows each other within the development community. They know exactly when someone becomes available and if they would fit in the team. This is a far more powerful approach compared to what a recruiter can achieve. Sure, use recruiter a network as well, but the really good developers have already switched jobs/assignments before a recruiter is aware of this. They've already been approached by another developer during a local meetup. Really, developers can be your best recruiters!
Tools like JIRA, TFS, or any other work-tracking system are only used if the Development Teams considered it useful themselves.
Not because it is such a convenient tool for others in the organization to track the progress. This will only create a culture of fear in which Development Teams feel they are being monitored.
Developers are encouraged to contribute to the wider community.
This can be by writing articles for tech sites, speaking at seminars, attending meetups, offering to coach and/or mentoring. Every community depends on the contributions of its members. Being part of a thriving community will help developers gain innovative ideas, solve problems with peers, and expand their individual networks.
They take care of their own "HR Process."
Developers give each other feedback and provide tips for personal growth opportunities.
I've worked with teams that even took care of salary increases and how a bonus should be divided.
Although this didn't always work out ideally, the signal the organization provided of "we trust you" did create a culture of ownership where self-organization more easily occurred.
Attending training and workshops is strongly encouraged.
Taking days off for this wasn't a painful and even humiliating procedure by asking for permission. I've always encouraged developers to attend public workshops and classes instead of in-company training. By participating in public classes, they meet other developers, learn about software development in a different context, and open up for new ideas.
There is sufficient time for R&D.
This could be jointly reading a book or watching a video and sharing findings among each other.
Organizations that have Development Teams fully scheduled with "customer work" will eventually pay the price.
Stress-levels increase, quality drops, and innovation will fall apart. We've always scheduled roughly one day per week for R&D. Sometimes we used a fixed day for this, but I've also been part of teams that preferred R&D weeks.
Pair programming is encouraged and not considered a waste of time.
Pair programming has lots of benefits. For example, it stimulates collaboration and shared understanding and improves the quality of the code. In my experience, by doing pair programming you deliver better products even faster because you've got less re-work or bug fixing afterward. So, it's definitely a practice I strongly recommend.
They choose to use Scrum themselves.
Or Kanban. Or XP. Whatever supports them the best in doing their work. The framework or methodology should never be the goal of itself. It should be an enabler. Involve the Development Team in creating a way-of-working that benefits them the most.
They have fun. Lots of fun.
This should be part of any kind of culture. Some organizations have become so serious nowadays. Have a bit of fun. We're spending so many hours together at work, why not just have an awesome, fun, and useful time with each other?
Conclusion
These are examples that in my experience help grow a Developer Culture. The order is completely random; it's just how it appeared in my mind! As mentioned earlier, if software products are your core business, growing such a culture isn't optional. It's crucial for the existence of your organization!
What's your view on the importance of growing a Developer Culture? What are the examples you have experienced?
In February 2020 we will host a 2-day workshop on "Developer Culture" with Darcy Dwyer , Jeroen de Jong , Peter Gotz , and Thomas Schissler . We will be using Liberating Structures to engage a large group of developers to share stories just like the ones in this post and to develop and build strategies to create "Developer Cultures" in your team and organization. If you're interested in joining, you can already sign up here . Take as many members of your Development Team with you as you can.Further reading
Published at DZone with permission of Barry Overeem, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments