5 tricky developer personalities — and how to rally them

In the breakneck world of DevOps, teamwork is table stakes to success. Development teams  must work closely and collaborate frequently, and ideally, with a positive attitude. When one or more team members are difficult to work with, they can set back deadlines and dampen morale. DevOps managers should focus on modifying those behaviors and providing incentives for change, rather than penalizing employees – or worse, ignoring the signs. Here are a few examples of “problem children” on development teams. You might recognize some of these traits in your colleagues and direct reports.

1. The Cowboy

This personality is a free spirit. He pushes back on estimations, plans, meetings, and documentation, preferring to work organically rather than under the structure employed by modern development teams. It’s common to find developers acting as cowboys — creative people are often independent by nature. Yet cowboys who go off the beaten trail too far can mess up planning and team-based deliverables.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1882720,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,","session":"C"}']

What to do: To rein in that cowboy, take some time to re-educate the entire team on the core tenets of the Agile Manifesto. The broader message here is that Agile values the right mix of process and controls as much as speed. Another idea, which has separate merits, is to introduce test driven development (TDD) or behavioral driven development (BDD) methodologies, which would force more accountability and transparency into the process.

2. The Tardy Teammate

This personality might be the smartest coder on your team, but she often misses deadlines for delivering code, estimates, designs, mockups, and so on. These individuals are probably the same ones who turned in assignments late during high school and college, driving teachers and parents crazy. They may have good intentions but lack some foundational organizational skills and focus.

What to do: The tardy developer often underestimates the effort to bring large projects to fruition, or might simply get easily overwhelmed with the bigger picture. Either way, the manager can reduce stress by breaking projects down into smaller assignments. The tardy developer will also need more manager oversight until they begin delivering on time.  Here are a few more ideas:

• Require developers to present demos of their work during the sprint cycle. This keeps everybody accountable without singling out the tardy ones.
• Paired development, typically used when training new or young developers, can also work in this scenario. By pairing a slower developer with a fast developer, the slow one should learn some tricks to be more efficient.
• Introduce project management tools that make tasks easier to track, organize, and complete, such as Jira Agile. You can set up such systems to send alerts to developers when they are falling behind schedule.
• Reward developers for delivering on time and with quality, with bonuses or other perks like an extra vacation day.
• Go with the flow. It might be okay to tolerate a bit of lateness on your team, especially if you have adopted Continuous Deployment practices, where the team releases code as it is ready. That way, you can still release the majority of features on time, while not forcing the team to wait for those developers still in progress.

3. The Meeting Misser

Let’s face it, most creative and technical types don’t like meetings. Yet when a developer is continually skipping standups, retrospectives, and other important team meet-ups, it becomes a problem for the entire Agile team. There are gaps in information, and pretty soon, other developers wonder why they have to show up.

What to do: First, take an inventory of the meetings that are being held regularly to ensure they are actually necessary. The best Agile development teams are co-located and can resolve problems in real time, but most problems can otherwise be solved using collaboration tools and hallway meetings between the team members involved. Status updates too are just as well delivered through Agile ALM and project management tools versus in physical meetings. This is all part of the Agile/DevOps process. Divide larger teams into smaller ones, which encourages casual collaboration. By rejiggering the focus from meetings to teambuilding and collaboration, everyone benefits. When meetings are necessary, whether to get a project off on the right foot or with a high-performance team under tight deadlines, make them productive. That means having an efficient meeting leader who sticks to the agenda.

4. The Silent Skeptic

Developers who are unusually quiet – to the point of insolence — come off as disinterested and unapproachable to teammates. These individuals might be unhappy at work, or are so introverted that they don’t fit well into Agile teams. If the person is a valuable individual contributor, it’s worth trying to root out the issue, and if they’re not, why are they on the team?

What to do: Some people want to share ideas, but not in a public format. Schedule one-on-one meetings with the silent skeptic, and try tools like TINYpulse to gather anonymized feedback. Other ideas include:

• Pay bonuses for team performance rather than individual output. This could motivate the silent type to contribute more publicly.
• Schedule time with the developer to work on career goals and to solicit feedback that might indicate problems with coworkers and managers or unearth a personal issue.
• Make sure that the loud voices on your team don’t overtake meetings and get-togethers.
• If the shoe won’t fit, don’t wear it. Set expectations for change with reasonable deadlines and ample support for the individual to adapt to collaborative Agile and DevOps processes—and be clear on the ramifications of not doing so.

5. The Metrics Manager

This spreadsheet-lover needs traditional development metrics so they can micromanage their projects and teams — or simply satisfy their numbers obsession. Agile metrics are best for delivering valuable software to the customer on time, with quality; they’re less useful for tracking the contributions of individual teams and team members.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1882720,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,","session":"C"}']

What to do:  Metrics are important to any Agile team, but only if they are the right ones. When a manager is derailing an Agile initiative due to an obsession with a particular metric, try to tie their concerns to a particular business driver – such as product quality, user experience, or customer satisfaction, using well-defined Agile metrics (such as NPS for customer satisfaction). Consider bringing in an outside voice, such as an Agile coach, who can educate managers on modern metrics approaches for development.

Developers come in many colors and flavors. Those personality differences can make a team fun and high functioning, or dysfunctional. Understanding the difference and taking action to correct problem behaviors in a supportive way helps developers be more productive and happy on the job.

Kevin Dunne is VP of Strategy and Business Development at QASymphony.