Assessing Coachability and Accountability in Software Engineers

Assessing Coachability and Accountability in Software Engineers

Coachable and Accountable

The operation of a software team is a fluid situation. Technologies become obsolete, frameworks come and go, and process methodologies are continually changing. This environment creates numerous coaching opportunities for both teams and individuals. The willingness to accept coaching is a key characteristic of any great engineer.

Let me introduce you to Ted. A software engineer of amazing talent! He could solve any technology-related problem he encountered. He possessed extraordinary intelligence. He was passionate about technology. He was constantly producing creative solutions to fix difficult and long-standing issues.

Yet, for all his ability, Ted possessed one debilitating weakness. It would likely derail his promising career. He had a toxic attitude! He possessed more intelligence than his peers. Unfortunately, it was something he frequently reminded them of. He berated other’s ideas. He was constantly attacking the solutions of his peers in ways that became personal. He was extremely sensitive to criticism and feedback. He was not particularly receptive to ideas other than his own.

He was followed by a trail of chaos and low team morale. Ted received coaching and feedback from his manager numerous times. Yet he refused to change. Inevitably, Ted was encouraged to move on.

Ironically, while his personal production and work output were incredible, the collective team output improved when he left. It was a sad case of addition by subtraction. Yet another example of how amazing talent is not enough to overcome a miserable attitude.

Engineering teams generally have a couple expectations when coaching moments arise, specifically those related to non-productive behaviors by an engineer on the team. The engineer being coached must own their behavior and make improvements based on the coaching feedback. Equally important, the engineering manager must to hold all engineers accountable, and the expectations should be explicit, fair, and apply to the entire team.

I was once part of a team that had some troubling behavior from one engineer. This engineer routinely failed to follow the development processes established by the team. He often failed to write tests for his code, and occasionally would introduce changes directly into the production environment without first testing in lower environments.

These changes caused a number of production incidents. When some of the other engineers brought their concerns to the engineering manager, the manager made excuses for this engineer and the concerns were dismissed.

This had an interesting effect on the rest of the team. By not holding one engineer accountable, the team collectively began to adopt many of these poor engineering practices. This behavior had become socially acceptable. This practice continued until we got a new manager who held everyone equally accountable, and who didn’t tolerate lackadaisical engineering practices.

Engineers who consistently fail to take accountability for their actions and behaviors are unable to achieve their full potential and exhibit a number of the following behaviors which are cancerous to team morale.

  • Defensive in feedback situations – it’s extremely difficult to coach an engineer who refuses to take feedback or admit when they’ve done something wrong.
  • They find blame elsewhere – the attempt to cast blame elsewhere will divide a team, especially if a manager fails to hold the engineer accountable.
  • Not interested in personal growth – – the lack of interest in learning and personal growth is a significant liability for software engineers. The pace of change dictates that engineers are continuously updating knowledge, learning new frameworks, and adopting new processes and technologies.
  • Unwilling to be vulnerable – this behavior often manifests itself among lead engineers who feel threatened by junior team members, especially those junior members who have more knowledge about a particular topic or technology. However, in their effort to create an invincible façade, these lead engineers limit their learning and growth opportunities.
  • Not open to looking at situations in new ways – some engineers get so set on a particular idea that they close their mind to other possibilities. This is particular true of engineers who tend to get emotionally invested in their own ideas.
  • Not open to experimenting with their behaviors – an extremely damaging behavioral characteristic in which engineers are not open to trying new ways of doing things. They not only are resistant to change, but are in open defiance of it. These individuals are cancerous to morale, and need to be removed from the team.

Sample Interview Questions to Assess Coachable and Accountable

Tell me about a time when you helped skill-up or coach a team member on a particular technology. I am looking to learn about a candidate’s propensity to help others and better leverage their skills to help improve the overall effectiveness of the team.

Talk about a time you had to give constructive feedback to a member of your team. This is an opportunity to learn how open a candidate is to providing feedback, as well as learning about the approach they take when providing it.

Talk about a time you received constructive feedback from a member of your team or your manager. I am interested in how a candidate handles feedback. Do they take responsibility for their actions, or do they continually deflect blame to others.

Tell me about a time when you were asked to do something in a way that was different than you were used to? How does a candidate navigate change? Are they resistant? Do they embrace it? Are they comfortable being uncomfortable? Due to the pace of change in technology, it is important to hire engineers who are continually willing to embrace change, while avoiding those who are typically resistant to it.

Related Posts

Do You Lead a Software Team?

Attention all leaders of software teams! Are you interested in discovering a consistent framework for evaluating software engineering talent?

  • Are you a Software Leader who has to hire the right talent?
  • Is this an area that has been hit and miss in the past?
  • Do you want to make sure you get it right next time and every time thereafter?

The most important responsibility for a leader of a software development team is to hire the right talent. Hiring the right team will make you look good, regardless of whether you have any faults and weakness. However, if you lack the ability to properly assess engineering talent, it is highly likely that you will fail.

This book will help you conduct a complete talent assessment of interviewees without focusing too heavily on a candidate's skills and knowledge and will help you to:

  • Understand why competency interviews are so important
  • Identify the best software engineering talent
  • Identify essential software engineering competencies
  • Ask the right questions
  • Educate your interview team to create a consistent and reliable process
  • And more...

It doesn't matter if you are the best leader in every other way, the universal truth in software engineering is that you can't lead poor talent to do great things!

But with this book you can eliminate having poor talent in the first place and make sure that only the best people work for you. Every time

Get a copy now. It will change the way you hire forever!