This Valentine’s Day, take some time to think about the people who come to mind first when you think about old St. Valentine: the Engineers you manage. To keep your Engineers happy and productive, it’s important to show them that you care about them. Here are five ways to demonstrate your concern for your Engineers’ well-being.
This is one area where an ounce of prevention is worth a pound of cure. Yes, automating your deployment process will take time and you might need to invest in software. But, “Complex, painful deployments that must be performed outside of business hours contribute to high stress and feelings of lack of control,” the authors write in Accelerate: Building and Scaling High Performing Technology Organizations. The number-one problem with Agile development is lack of confidence in deployment, according to Stackify CEO Matt Watson.
“Performing and validating a manual deployment process is often a time-consuming, thankless task,” Development Manager Chris Smith writes. “This job can fall to developers and testers in a development team who would otherwise be spending their time producing the next set of awesome features and improvements to the software.”
Ideally, “Deployments should be the most boring task of the workflow,” Cloud Architect Christian Meléndez writes.
We know deploying frequently and in small batches and continuous integration/continuous delivery are DevOps best practices. But it’s hard to do that until we make deployments less risky, painful, inconvenient, and complicated.
To do this, write scripts to deploy specific actions in a specific environment in a specific context.
For more advanced automation, use any one of the software deployment tools on the market today. Many CI/CD tools also support automated deployment. Tools like Terraform, Ansible, and Jenkins. You can have all your scripts in version control, and that will be the only source of truth. That means everyone will know what changed, as well as when and why it changed, not just in code but also in infrastructure and deployment pipelines.
APM tools like New Relic let you monitor all of your KPIs and track deployment so you know the source of problems when they arise. Using feature flags will increase your confidence when it comes time to deploy. As can using a checklist. Another tip: Blue/green deployment.
In Accelerate, the authors recommend asking Engineers what their roadblocks are and working to clear them to help prevent burnout in software engineering organizations.
An impediment or blocker is anything that slows or blocks a team from making progress. Examples include a hurricane in NYC, a tsunami, a people issue, or the lack of a babysitter.
“In fact, since nothing we do is perfect, every team has at least 900 impediments, things that can be improved somehow,” according to Lean Agile Training. “The only real question is, what are the top 20 things to improve? Or problems to address.”
One huge, underrated, blocker is moving between to-dos. Task switching creates brief mental blocks that can decrease productive time by as much as 40%. And nearly half (45%) of workers get interrupted at work at least every 15 minutes. Research indicates that constant interruptions at work lower your IQ as much as losing one night’s sleep and twice as much as smoking cannabis.
Books from productivity gurus from Cal Newport to Nir Eyal show that deep, profitable work requires chunks of uninterrupted time that are at least two hours, preferably longer. It’s in those periods that most workers get the majority of their real work done in. At Clockwise, we call this Focus Time.
A lack of Focus Time is often a significant blocker for Software Engineers. One quick way to see how much or little Focus Time your team has is to use our free Calendar Insights tool.
Once you start recording blockers, also note down how long each took to resolve. This is helpful information when planning, evaluating Engineers, and talking with external groups.
Unless there’s a very compelling reason not to, the Accelerate authors recommend you let your Engineers choose their own tools. Choosing their tools helps them feel invested in their work. And the data shows that having the tools you need to do your job is a major factor in job satisfaction and continuous delivery success.
Of course this freedom for devs comes with the cost of buying, supporting, and communicating with a greater variety of tools. To help make it work, Google recommends the following best practices:
1. Create a pre-approved list of tools
Have representatives of different teams and cross-functional areas create a list of approved tooling. This list should be large and diverse enough to address the majority of your organization’s needs. You might want to include programming languages and libraries, testing and deployment tools, monitoring infrastructure, and data backends. Product managers, developers, testers, and operators should be included in the decision-making process.
2. Periodically review the tools
Regularly revisit this list to be sure everything still belongs. This is a good time to discuss and demonstrate new technologies to consider adding.
3. Define a process for exceptions
Sometimes you’ll need or want to deviate from the list. Each time you use a new technology, document what the new tool is and why you used it. This can help when it’s time to troubleshoot and maintain the project. And it helps stakeholders decide whether to add the tool to the list.
Leaders who invest in their Engineers’ skills and capabilities get better results, according to the Accelerate authors. It’s also helpful for retention, since the average worker values opportunities for career growth more than any other workplace perk according to Gallup, Deloitte, and Google.
Rather than signing every one of your Engineers up for the same conference, begin by adding the question to your one-on-ones: “If you had to pick one skill you want to level up -- be it technical skills, leadership skills, speaking skills, soft skills — what would it be?”
You could also ask this question: “How can I create opportunities for your growth?” If that doesn’t yield much, try “What are your long term goals? Have you thought about them?”
Once you know what they want to learn, set aside the time and budget for them to do so. Keep your bookshelf stocked with relevant books. Point them to General Assembly. And make sure it’s culturally acceptable for Engineers to spend work time reading and taking classes.
In Indistractible, Nir Eyal writes that the Google study of effective teams showed that successful teams had five characteristics:
The last trait, psychological safety, was by far the most impactful and underpinned the other four. Originating with Organizational Behavioral Scientist Amy Edmonson in a TEDx talk, psychological safety is “a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.”
Leaders can foster the psychological safety required for open communication by:
To show your Engineers that you care, make sure deployments are as smooth as possible, record and remove blockers, allow people to choose their own tech, invest in your Engineers’ talent and skills, and create psychological safety at work.
And if all else fails, bring wine and chocolates.