Things Strong Developers Do That Drives Their Team Crazy

After years of nose-to-keyboard and countless nights of hairpulling, debugging... you've unlocked a level of ultra-learning you couldn't have imagined when you began programming!

How can any one problem be so doable?

Why aren't people as excellent, productive, proactive, and motivated as you?

Why don't they communicate with each other, why don't they want the best for the team?

I've noticed, it's really easy to develop tunnel vision about chasing a goal or milestone, and to forget about how your team feels.

If they're not aligned and relationships are not going well, they will in fact, give you their even-worst!

In hindsight, I believe my own impatience and lack of empathy made me a terrible undergraduate teacher. I expected everyone to share the passion I had for my discipline.

Some people go to school like they have to do laundry. Some people work just to do an okay-job, and that is absolutely ok!

I have been reflecting on this Patrick Kuo talk on challenges and mistakes that developers face as they transition into leading a team.

I have made many flawed assumptions when I thought I was the most rigorous on a team that I would be able to, through non-stop onboarding and one-on-one time, influence others to do better -- to be like me!

Here are a few things I've found compelling about Kuo's talk that resonated with me in the times I've worked with leads/senior of differing schools-of-thought:

• Just telling people what to do without considering their interests or strengths, and furthermore not taking the time to understand what their perspective and work style is shaped by-- very likely their own traumas and experiences of others possibly-flawed leadership styles too

• Making all the tech decisions, therefore limiting the amount a team can feel in charge of influencing outcomes.

  • There's scenarios in which quick decisions need to be made, especially on a very tight timeline, however, hearing others' reasoning as to why they support/disavow a specific decision should be part of your ongoing duty to understand the impact of the decisions you've made.

• Refactoring features that others just finished to meet personal expectations of standards, which demoralizes the dev who just completed the ticket

• Doing more work by volume without communicating with the team about expectations, which prevents people from learning through trial and failure on tasks of differing difficulty, --and also sets up a cycle of them expecting you will pick up their slack.

  • I've gathered my job is to show other devs how to do something better... and also give them the agency to decide if they want to follow. If they experience failure, this is something they need to realize and own as part of their career.

• Simply delegating tasks without onboarding. Individual team members require context to be able to complete their tasks. If you aren't able to find another person to sync with them, then you are responsible for equipping them to have the resources they need to complete their task.

• Doing only/all the work that you're interested in, instead of thinking how you can do to support teammates and develop each person's technical and personal strengths.

  • This means allowing others to tackle challenging technical issues, not doing them because you are interested or have a high investment in them. You have other things to do cross-team, cross-department. You can step in to help when they can't figure it out.

Here are a few I've reflected on as being particularly unproductive for myself and the general productivity of a team:

• Writing detailed tickets and docs and expecting folks to just read and follow suit, instead of having folks understand why writing initiative is important on a team, and to develop that muscle of writing down instructions to make others' lives easier when they have to review or test their work.

• Expecting people to reply or make decisions right away, or work at the same pace and style as you. You are the "fall guy/person" on the deliverables, but it's also your job to anticipate other folks' comfort level and work pace, how they feel motivated and empowered.

I've mentioned weaknesses I'm working to improve in this post. There's every chance feedback from one occasion, doesn't apply to a different situation, and one can overcorrect too.

I believe that reflecting on missteps creates opportunities for people to provide an alternate point of view for whether your own assessment on your performance is accurate, or overly critical.

I love working with people, and it's quite a shift how I've gone from working as an introvert scrappy solo artist to feeling like I need a group of people to work with to create anything.

All these are luxuries and privileges to be able to meditate on how I get to do what I love, and better, as work.

Questions for developers, quality analysts and PMs who are leading with or without authority and tech leaders out there:

• What have you noticed yourself doing to cope with stress, and how has that impacted your team?

• What have you tried to do to make others feel safe and understand how to work better together?

• How have you handled less communicative or introverted personalities who don't share the same communication style?

• What are moments for you where you realized a team is not functioning as you thought, and what have you done or changed in your approach to help them?