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!
I've been reflecting on this Patrick Kua talk on challenges and mistakes that developers face as they transition into leading a team.
I've 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!
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!
Here are a few things I've found compelling about Kua's talk that resonated with me when I worked with leads from 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.
-
Making all the tech decisions, therefore limiting the team from feeling like they can influence outcomes.
- There are scenarios where quick decisions need to be made, especially on a very tight timeline. However, hearing others' reasoning on why they support or disavow a decision should be part of your ongoing duty to understand the impact of decisions you 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 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 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 have a higher 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 helping them 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 to 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?
Top comments (16)
Helpful stuff. I also often lack the patience or desire to explain why this way or that way.
I really like working with a strong team, when cool ideas come from many sides during brainstorming. When you just started to explain something, and they already understand what you mean and only look at the way to solve minor issues.
The opposite of a weak team. When you share an idea and there are a lot of questions like "what is a proxy", instead of questions about your idea. Few people understand what you are talking about. No ideas or indications of your miscalculations. It gets boring quickly... So far I have not been able to find for myself what to do with it, except to leave such a team or silently do my job as described in the article.
Re: Asking of basic questions. I really try to make it clear to a team that there are no stupid questions. Granted, there's an expected amount of self-help that's expected at work (Googling/reading dev.to or Stack Overflow) in order to be asking more productive questions. I've worked in some environments where no one would ask any questions in the #dev channel, and this seemed give me an impression there was either a fear-of-looking-dumb, or an unhelpful engineering culture at work.
Thanks for your comment btw, looking forward to hear more on your reflections!
Here I completely agree with you, the absence of questions is much worse. I'm not talking about stupid questions. And there is no problem if people ask questions during the presentation that are only indirectly related to it. But it's very different when you're doing brainstorming. This is not a place where you explain to people about different technologies or patterns for several hours, this is a place where you would like to hear different ideas for solving a particular challenge.
But what to do if this happens like this:
On the one hand, this meeting did not give anything significant. On the other hand, the team feels part of the solution (maybe), and this is also the result. But I would like more, I would like to get advice. To understand what are the pros and cons of this solution. And I would like that someone looks at the idea from a different angle.
Any ideas what can be changed in this case?
I get what you mean re: a team that doesn't have strong critical or deep independent thinking, nor answer with much gusto for solutioning, makes me feel unsure and scared... I wonder if it means we have the responsibility to nurture each person's instinct for learning the basics and deepening their craft, or that we need to take less of an open model of consult-and-decide ...
it's correct, and which option is right? :)
There's no "right" I don't think, and every approach I've taken with others was tainted by the bias of what worked for myself at previous companies and teams. The title itself is new to me, but I'm no stranger at working with large groups of people in a volunteer, organizing or collaborative sense. I think it's much easier when folks are united under the same vision and goal--sometimes it's our jobs as leaders to instill that or make decisions and expectations clear about consequences of not contributing sufficiently... otherwise, it's like taking a basket of tricks and trying what works for each person, understanding the situation correctly and staying open to feedback upwards and laterally imo... I think I've found that asking everyone/everywhere about how I'm doing and how to succeed unlocks more about myself, my values and what kind of company (culture) I want to be in...
To me I recognize I had the greatest success by taking the time to get to know each person who I worked with (outside of group pressures, presentations etc) and learning what drives/annoys them, and how to work together.
Re: strong team or weak team... I don't believe it's always so absolute, most teams have a range of experiences and more often, communication issues that make working together well difficult. For example, the times I worked with folks with less experience but higher skill than me in an area. They were independently very productive but were not communicative about changes with the rest of the team, and also not open to being challenged. That aspect proved to be the most difficult even if they were the strongest dev and leading a project... everyone was jostling to keep up with them or trying to figure out what they did.
Spot on - a good leader doesn't play the control freak or (worse) the dictator, doesn't micro manage, doesn't try to do everything himself - a good (or let's say, effective) leader facilitates, encourages, mentors - tries to make OTHERS do better work.
I still feel like crying when I think about a totally brilliant manager/lead I worked for before... they would be available for bouncing ideas off, talk me through when I was stuck, and just allow me to take on the challenges of presenting solution architecture and estimates while being the shield/stop gap if the client bit my head off. It was such a great, inspiring example.
Yeah that sounds exactly like the way it should be :)
Since you replied supportively, I realize that being a judiciously empathetic leader is really difficult. It's hard not to measure others competence by your own yardstick and how much they remind you of yourself earlier in your career... perhaps those great manager/s of mine were good at handling this too
I'm new to doing all this with the title... I wonder how you deal with fear and resistance to changing circumstances amongst teammates? I've tried educating others on step-by-step chunking down, debugging, determining severity levels of bugs, or uncontrolled aspects of business needs which means surfacing tradeoffs... maybe it is simply that people want to vent?
This vibe easily spreads like wildfire and it's quite emotionally challenging to deal with.
What do you mean by "fear and resistance to changing circumstances"? it's a bit abstract ... yes I'm sure that sometimes people just want to vent, and sometimes it's probably even better to let them rather than go against it ...
I'm trying to be inexact so as to preserve the anonymity and difficulty of the situation I'm experiencing currently but have also seen before...
You're right though, recognizing whether people want to vent or want an immediate solution to their problem is also a muscle I need to build.
This is really helpful as I myself am transitioning from development only to a team leadership role. Thanks a lot! π
Congrats on your recent growth! I'm in a similar situation, and there's SO much to think about! :D