This blog post will be my last post in a series about good Drupal leadership. After exploring how good Drupal leadership should have a plan and process supported by resources and relationships, I felt it necessary to end with miscellaneous skills and drupalisms.
The most miscellaneous Drupal'ism an organization's Drupal leadership needs to consider is that the software and community are interdependent.
Wearing two hats
Drupal is software built by a community. This reality means people wear two hats - one which focuses on the benefits of the software to their organization's business goal, and the other understands and values the collaboration of the community building the open source software.
The first hat’s focus should always be on the success of your organization's business goals while the second hat’s purpose is ensuring that Drupal and any open source tools continue to meet the organization's business goal by contributing to them in a thoughtful and meaningful way. It is okay for businesses to ask "what is in it for us?" when contributing to Drupal. No organization should blindly contribute, and it is up to good Drupal leadership to guide an organization's contribution. There are many productive and rewarding ways for an organization to get involved.
Leading by example
When I look at the leadership of various agencies in the Drupal community, occasionally, there is a trend where some technical leaders will get their hands dirty with Drupal. Some leaders build their blogs in Drupal. In contrast, others maintain entire ecosystems within Drupal. Having leaders with some hands-on experience with the software and community is invaluable.
Leading through encouragement and recognition
Everyone wants to be appreciated for their hard work, and making open source contributions should be part of an organization's process. Encouraging developers to get involved and continually recognizing an individual developer's contributions and acknowledging how it helps the organization's goals and the stability of the software it relies on can go a long way.
Drupal has reached a scale and complexity within most organizations that warrants building an internal community around maintaining and improving the software. If good Drupal leadership can create an internal community around Drupal, it will inevitably lead to helping the larger community. At the very least, an organization's team may attend a few Drupal events, leading to a few discussions, and hopefully leading to a few lines of code being contributed back to the software.
Taking leadership to the next level
These posts are for business owners and organizations thinking about adopting Drupal as well as organizations that have already adopted Drupal and need help taking their engagement with Drupal to the next level. The simple fact that there is always a next level to Drupal makes it unique and challenging.
Drupal is not an end-all solution that provides a perfect answer. Drupal does provide an arsenal of tools with a community-driven army of people building and maintaining these tools. Organizations seeking to get the most out of Drupal need to have leadership that helps plan the implementation, guide the process, mentor the resources, and build relationships and partnerships. These tasks, combined with the understanding that getting involved in the community and contributing to the software, can benefit an organization's business goals.
Why did I write these posts?
Questioning what is good Drupal leadership is personally and professionally important to me. Looking for and helping to provide the answers is also a priority. When I researched these topics, most of the blog posts and articles were from agencies and service providers trying to help their potential clients while selling their services. Drupal may be at some turning point. As a community, we have succeeded at selling Drupal as an open-source enterprise Content Management System (CMS) and platform for building digital experiences (DXP).
The latest Who sponsors Drupal development? (2020-2021 edition) shows that individuals and organizations are contributing less. Dries offers some thoughts as to why. We need to recognize this change in contribution as a possible turning point. These "Good Drupal Leadership" posts are intended to nudge the community away from selling Drupal and explore the need to do Drupal better. Doing Drupal better starts with the organizations using Drupal and the end-user, not the companies, selling Drupal. Drupal's competitive advantage is its flexibility and community compared to other leaders in the CMS and DXP space. Anyone recommending or implementing Drupal needs to own these challenges that come with these advantages.
Where should this discussion end?
Maybe there is no end to this discussion, just a plan with a process that requires resources built by establishing relationships. Everything I have discussed has been sprinkled with a nudge for organizations with good Drupal leadership to get involved in the Drupal community.
None of these tasks for building good Drupal leadership are final; they are iterative. Where is your organization with your iterative engagement with Drupal, the software, and the community?