3 Key Ways to Make Sure Your Best Developers Are Happy

Posted by George Michie on Aug 31, 2015 11:16:00 AM

It's not easy to build a great team. And, once you've built it, maintaining such a team can be even harder. Collaboration is often the biggest challenge, along with finding the right ways to foster it. A successful organization must be more than the sum of its parts—after all, that's why we found companies, recruit around the world, pool resources, cooperate, and, as a result, accomplish great things, far beyond what any individual could do.

For a modern day engineering team, "collaboration" cannot involve putting blinders on your developers and telling them to pound out some code. Even if they're brilliant, and even if the code is excellent, that kind of approach disregards the value that comes with communication between teams and across the company. And in the long run, that collaborative value will be worth much more than even the work produced behind those blinders.

computer.jpgImage Credit

DevOps principles have taught us that team building must go beyond conventional team designations. That means giving developers the opportunity to break down their silos and the ability to work confidently inside arenas that are normally specialized, such as the database. Toward that end, we've put together this list of 3 key ways you can make sure your best developers are happy. In an organization that accomplishes these goals, developers will be able to collaborate, will not feel boxed in, and, ultimately, will be able to push better code faster.

1. Make your developers a partner to the business rather than a servant to it.

Some types of organizations—say, a law firm—may just want its IT team to do what it's told, and that’s not unreasonable. However, for businesses where software development plays an important role, developers should have input into what gets built, not just how to build it.

This is more than a common courtesy. Developers often have a much better sense than business leaders of what’s possible to deliver, and by engaging the creative minds of engineering teams, you meaningfully bring powerful resources to the table. By allowing developers to get involved and have a reasonable, valuable influence, you prevent them from seeking greener pastures.

Invite developers to your product development and business road map meetings, while rotating through the developers’ department, so everyone who wants to participate has the opportunity. Publish the notes or videos from the meeting. If success or failure in business depends on the quality of ideas, getting more sharp people to think about what’s possible, to understand the lay of the land, and to be vocal in where the company goes next makes for an exciting workplace. It will also be more functional and more creative, with more types of thinkers participating in important conversations.

Too often the software development team is relegated to a role of waiting for instructions, having little or no say in what they’re asked to do, and, woefully, having little real understanding of the business, the competitive landscape, the goals of the company, etc. What a waste. Some developers may prefer to just write code, but experience suggests that many of the very best prefer a more challenging, engaging, and creative environment. Simply asking them to knock out tickets is a good way to both miss business opportunities and lose top talent.

2. Break down hyper-specialization in or around the engineering team.

Yes, specialization creates efficiency, and everyone likes efficiency. Having every developer familiar with every part of the code base is impractical in any scaled department. It takes too long for a developer to wrap his or her head around totally unfamiliar code.

However, specialization has a knack of being taken to extremes, which destroy collaboration, reduce creativity, and turn the workplace into a daily grind.

Boss: “You’re really good with our API integrations and updates. Let’s have you stick to that… and only that....”

Developer: “Um, okay…can I use you as a reference?”

Giving developers periodic opportunities to work on different types of projects in different parts of the code base has many benefits. Consistently bringing in a new set of eyes to an “old” set of problems is a great way to spark discussion, foster collaboration, and, ultimately, create better solutions.

Exposing developers to many different challenges broadens their horizons (which they can then bring back to their core area of operations), expands skills, and opens managers' eyes to potential role shifts within the department. It also creates robustness in the sense that no single person or team in the department becomes a single point of failure. It also lends variety to your teams' work lives, and that will make the job altogether more fulfilling and engaging long-term.

On paper, these periodic, short sabbaticals may appear inefficient, and the benefits can be hard to quantify. Mediocre managers avoid practices that aren’t easily defensible in measured ROI. Great managers understand the value of diversified skills and exposure, and their teams are more engaged, more productive, and happier. Keeping your best people happy reduces churn, hiring expense, staff shortages while roles are unfilled, etc.

3. Give your developers and DBAs common ground where they can work together.

As with development in general, some level of specialization is crucial to a high functioning team. Database Administration is done best by people with specialized knowledge, training, and experience. However, we strongly believe that every developer should have some understanding of database architecture, index usage, SQL, and execution plans, so that they can independently help DBAs head-off some problems that are foreseeable.

There is an analogy here to the automobile industry. For a time GM created a dedicated Quality Assurance team that would work on the floor of the plants as a check on the assembly line workers. Seemed like a good way to improve focus on quality. To everyone’s surprise, quality metrics all went downhill! What they found was that the existence of a QA team had two unexpected side effects:

  1. “Quality” was no longer the responsibility of everyone on the team—it rested solely in the hands of the QA Team.
  2. The setup  created a combative rather than a collaborative work environment. The QA Team were eventually viewed as the “bad guys” who got you in trouble, and promotions to that team betrayed relationships that had been built over time. GM learned that quality had to be in everyone’s job description.

Similarly, if smoothly running data systems are exclusively the responsibility of the DBA, developers will come to see the DBAs as a bottleneck, preventing them from moving faster because they have to wait for code reviews and to have questions answered. DBAs will come to view developers as problem children, messing up their house with sloppy queries, because database efficiency is “not their problem”—not conventionally at least.

That's where we disagree. Rock star developers with strong SQL skills have to go through the same review processes as less skilled developers, creating both inefficiency and frustration in a group that is disproportionately important to the organization. But when developers have a handle on the database and the resources to self-service, everybody is much happier.

Let the team thrive.

The relationship between teams doesn’t have to devolve into conflict. At VividCortex, we believe the key to breaking down these walls lies in database monitoring systems that provide DBAs and developers a single, powerful, easy to understand tool (i.e. not Cacti, Graphite, or Nagios) to see which queries cause problems, and even which queries generated by new code are likely to cause problems when implemented. When developers can independently understand the database, the team is more collaborative and effective all around. Imagine the benefits of being able to skip 50% of code reviews! 

  • DBA and developers’ time saved? Check.

  • DBAs have more time available to solve real problems instead of reviewing clean code? Check.

  • Developers spend less time trying to get questions answered and suffering fewer interruptions, because the DBA is more often available when needed? Check.

  • DBAs and developers enjoy work more, are more engaged, stay longer? Check.

Specialized teams with team-only goals are a business-school standard, but that approach creates barriers to organic, creative, dynamic, collaborative teamwork. The highest-performing development teams have found ways to enjoy the benefits of specialization without creating silos that bog them down and encourage the most talented developers and DBAs to go elsewhere. When you give your developers these kinds of opportunities, they'll be happy to be at your company—and you'll be very happy to have them.

What has your department done that has either helped or hurt teamwork, efficiency and morale?

Recent Posts

Posts by Topic

see all