Technical Leadership

Are You a Conscious Technical Leader?


How many times did you hear a story about a good software developer, whose performance went down after getting promoted into a technical leader role? Unable to focus on either of the duties, frustrating himself and the team, he ended up backing out of the position. Or, alternatively, he kept running the team, but was generating frequent issues with project delivery or employee attrition.

Sounds familiar? It seems to occur much too often in the IT world. Companies often end up losing a good developer for a weak manager. That’s why I believe we need more Conscious Technical Leaders.

pilot photo

A Conscious Technical Leader is someone who was able to make the mind shift after transitioning from a developer’s role. Someone who understands the difference in priorities and expectations, and was able to change their behavior to fit the new situation.

In my opinion, every development team needs a Conscious Technical Leader in order to be fully empowered, to operate in the most effective way, keeping both customers and employees satisfied. Even when it’s not a formal position, like in self-organizing agile teams – most of them could still benefit by having someone with these traits on board.

But what does it really mean in practice? In my opinion, you can call yourself a Conscious Technical Leader when:

  1. You understand that you’re not just a senior developer anymore.
  2. You put the needs of your employees as high as your own.
  3. You understand that leading is not the same as giving orders.
  4. You are focused on increasing your leadership skills and growing in that direction.
  5. You see employee satisfaction and engagement as a high priority, even during difficult times.
  6. You prefer to leave the most interesting technical tasks to your people rather than coding them yourself.
  7. You seek mentors among more experienced people in this role.
  8. You are able to identify the most important soft skills that you need to improve.
  9. You allow your team members to participate in decision making.
  10. You limit the time you spend on technical tasks to make enough space for leader’s duties – and not the other way around.
  11. You actively seek opportunities to help your employees, rather than having them apply and wait.
  12. You know you don’t have all the answers, and you understand you don’t need to have.

Would you add anything to the above list? Please leave your thoughts in the comments.

Management, Technical Leadership

Help! There Are Introverts in My Team


In my last post I described some theory behind introversion, and mentioned that probably most software developers demonstrate such type of personality. Today let’s discuss some practical implications it may have for your team and things to consider as a leader.

office photo

Brainstorming should be abandoned. You won’t get the best ideas, you’ll just hear the ones your extroverts can come up with off the cuff. Introverts need time to think through a problem, and they won’t usually say anything just to appear ‘creative’. Use different discussion patterns instead, and if you really care about valuable input, give your people some time to prepare.

Open spaces are counter-productive. They result in your most talented introverts being frequently distracted by the most ‘active’ employees. And you thought you can just put people together into a large room so that they ‘communicate’ and be more creative? Think again.

Some agile techniques require a second thought. Pair programming? Maybe two developers working closely together, communicating all day long, is still fine from an introvert’s perspective – when they know each other well… That’s yet to be researched though. Maybe that’s why some people consider such techniques to do more harm than good.

Review your recognition approach. Many of your team members might not actually enjoy the ‘unique opportunity’ to present their idea in front of the whole company… Some might even see it as punishment. You may still need them to do this, but don’t pretend it’s a reward in such case.

Collaboration is not always the way. We might have been too aggressive in promoting the collaborative style of work, thinking it’s a solution to all problems. Allow your people to work in a bit of isolation sometimes, give them more privacy, and see if the results won’t actually be better.

Limit the number of meetings. Well, nothing new here… Just one more reason to do it (does anyone even need it?!).

These are just some basic observations. I’m sure once you start to look at your team’s everyday work from this perspective, you will notice many more situations in which the environment doesn’t help your introvert team members. Feel free to share them in the comments.