An "engaged employee" is defined as one who is fully absorbed by and enthusiastic about their work and so takes positive action to further the organization's reputation and interests.
-Wikipedia page on Employee Engagement.
In this article, I explore four aspects of fostering developer engagement while highlighting how an organization might improve their development efforts.
I’ve worked as a software consultant for my entire adult career. I’ve been a member of many teams across different organizations and industries, being exposed to a healthy spectrum of engagement. All of the following observations and opinions are gathered from this unique perspective. Read carefully, smile frequently.
Encourage Innovation
Developers should feel empowered to try things. Things is an intentionally ambiguous term. The world of technology is endlessly huge, and organizations are in wildly different stages of adoption.
Innovation for your organization could mean trying out a PaaS offering for the first time in order to implement your next application feature. If you have a developer who can justify the change and is passionate about making this advancement, it would be a mistake to discourage her. You must be willing to let her try and fail.
Perhaps you have a developer suggesting a more rigorous code quality process, using foreign tools that he was exposed to at his last software project. Are you open to at least entertaining a demonstration or proof-of-concept?
Maybe you have a group of developers come forward to discuss switching source control technologies for their project. They strongly believe that making the switch will propel velocity and improve the development experience for the team. This technology has never been used in your organization, most of your IT department is unfamiliar with it, and you’re afraid of such a change. You oversee dozens of applications that are using the old source control system. Why make a change? Besides, you don’t want to disrupt the DevOps team. They seem busy.
But don't be too quick to say no. Keep in mind that when developers are passionate about trying something, it will likely be completed in addition to their original commitments, with pleasure. That's right. They will complete their work on the XYZ Widget AND implement their new innovative idea. This is a phenomenon called engagement.
Now, consider a developer’s path to process improvement at your organization. Is it one of exhaustive analysis, meetings, and closed-door discussions between parties that are completely disconnected from the day-to-day development work? How many layers of approval must be traversed before an idea can be explored?
If it’s painful to attempt improvement, improvement won’t be attempted. Once your engineers discover the uncooperative state of your development culture, attitudes will trend toward apathy. Great ideas will not surface, potential leaders will remain unidentified, and smart people will leave.
Don't make it difficult for innovation to flourish. Having an explicit platform or outlet for innovation is fine, but not completely necessary. The most important thing is that developers believe the organization is receptive to new ideas.
Define Requirements as a Team
Developers should not be treated like cogs in a machine, cranking out changes based on a list of requirements they have no say in. In order for them to be fully engaged, developers need to be included in requirement discussions early in the planning process. Not doing this will likely result in a waste of creativity and failure to implement the most effective. Follow that up with rework and mass disappointment.
We can observe this unengaging practice most commonly in waterfall environments.
The business asked us to make this widget. I’ve mapped the work to task #63, #64, #65, and #66 on my massive, incredibly inaccurate Gantt chart. This should be completed in three weeks. Here are the requirements.
Sounds engaging, right? Who wouldn’t be inspired to do a great job on this work?
Picking on waterfall is easy. It should be made clear that the early inclusion of developers is still very much a concern for Agile teams. It’s often not enough for user stories to be groomed and estimated by development teams. At this stage in the Agile process, the story may have already reached a rigid level of maturity. Developers will be less likely to speak up and present their valuable opinions or objections.
We’re talking about highly intelligent introverts who are likely to avoid conflict. Don’t expect them to be willing to disrupt the status quo and second-guess others’ plans in front the rest of the team. You’ll get developers talking much easier in a pre-planning phase. Shoot for a stage where the requirements are known but not fully baked. Maybe this is a grooming ceremony, maybe it’s even before grooming.
But what about the business analysts? Even if you have a fleet of highly technical business analysts writing insightful user stories after carefully coordinating detailed discussions with the business and technical teams, which I have never seen, it is necessary to pull in developers to help define the work they will be performing.
Overall, we want good development outcomes and we want developers seeing the work as their work--their project. When they discuss the software project with friends and colleagues, we should hope that they claim ownership. It’s hard to be enthusiastic about other people’s work.
Inclusive Design Decisions
Much like defining requirements, developers should have a voice when it comes to design and architectural decisions. Requirement discussions pertain more to the What and Why, while the architecture and design discussions affect the How. Since the development team is going to be implementing the software, it only makes sense that they can influence how it is done.
Having design and architectural decisions made in an ivory tower and handed down to the development team without any form of collaboration is demeaning and demotivating. If you have a development team that enjoys this type of workflow, chances are, they’re terrible.
Nobody will be enthusiastic about building something the "wrong way." It may not be the wrong way—it might be justifiably the best implementation plan. If this isn’t properly discussed with the individuals implementing the widget, they might not see it that way. So discuss, don’t demand.
I’m in no way suggesting that organizations get rid of architect-type roles, only that more of the individuals who spend the majority of their time in the trenches have a chance to affect design decisions. This point goes beyond engagement and motivation. Yes, developers are bound to show more interest if they are more involved in defining the work. More importantly, these days, you need them to be more involved in order for your organization to stay current.
The few folks in the organization that hold higher-level technical roles surely don’t possess all of the technical know-how, especially considering the current pace of change. In order to truly maximize the effectiveness of our dev teams, we need to find ways of harnessing the vast knowledge and experience of our full pool of software engineers. There is no doubt that there are tools, technologies, techniques, patterns, and architectural strategies that you are not leveraging, but should be—right now.
Remove Needless Process
Your developers are passionate about solving problems with their development skills and acquiring new development skills to solve problems even more effectively. Don’t disrupt that. Inspiration is fragile. Stay out of the way.
Don’t get me wrong, not all process is bad. Many processes are necessary and beneficial. For instance, requiring unit test coverage and code reviews before developers can merge code into a branch is a great process. It encourages disciplined, quality development practices and careful communication of code changes.
Also a good practice: brief, daily standup meetings. What did you accomplish yesterday? What are you working on today? What is blocking your work? Provided that detailed discussions are tabled for a more appropriate audience, full-team daily standups serve as a process that ultimately saves time by preventing other meetings. They also promote accountability and surface impediments that would otherwise be lost in a mess of emails.
… on the other hand …
Status reports. Logging time in three different systems. Scheduling meetings. Propagating project updates. Updating user stories. TPS reports. Attending poorly run meetings. Documenting and distributing meeting minutes. Updating business documentation. Submitting approval requests. Submitting access requests. Submitting whatever requests.
Would you rather have your lead developer spend 15 minutes on a status report or spend that 15 minutes researching the fascinating merits of the Functional Programming paradigm and its application to large software projects?
I appreciate that some of these things cannot be avoided, certainly more so for heavily regulated industries. I hope you can appreciate that some of them can be avoided. Carefully evaluate slices of your software development process from your developers’ point of view. What are the tasks that your developers perform regularly? Question everything that is not development related.
- Is this task really necessary? Does it add real value?
- Does my developer have to do this or can another non-development resource take this on?
- Was this process put in place to protect the project from complete morons?
Answer honestly and curb the lazy “that’s just how we do things here” justification. I don't accept that. If you’ve uncovered zero throwaway tasks after evaluating everything, you did it wrong. Even if developers simply perceive something as unimportant busywork, you must make revisions.
We can’t start a crusade against every non-development task, but minor inconveniences do add up. They drain motivation levels and distract from precious development time.
If you happen to have answered yes to the third question, prepare a list of names for HR and kindly explain your hiring mistakes. Not all developers are created equal. My entire dev team shouldn’t be banned from swimming just because a few bad apples peed in the pool.
Final Thoughts
Much of this article promotes the inclusion of the engineers that are actually implementing the work. Clearly mass inclusion with full consensus is unrealistic. Work doesn’t get done when everyone has a say and absolute consensus is the goal. Work can be done more effectively, though, when great ideas are allowed to emerge from the trenches. The key is facilitating a culture in which this can happen.
Please share your comments. Which engagement deterrents did I miss?
