Mark Pearl

What got you in management?

In the tech world most people became team leads because they were great coders and got a promotion, which then meant you got to do less coding and attend more meetings. Alternatively you started a tech business and the product did well and suddenly you started to have to hire other developers.

I kept trying to be a manager without letting go of my programmer identity.

Five essential concepts to most managers need to know and implement

  1. Keep your eye on the entire project - you need to know all the moving parts
  2. Call BS on idealism and shortsightedness - easy to underestimate how long something will take and overestimate your skills
  3. Realize that communication, not production is your priority - create relationships with your team and your stakeholders
  4. Communication is the most important aspect of your of management and core to your job
  5. Don’t step back into the orchestra, especially during crisis time - when things are going wrong, you need to help your team get to a safe place, don’t take over their work

It’s easy to get caught in the trap of reacting to every problem that comes through. Get your head above the fray and find real leadership solutions.

What do you loose when you become a manager and don’t stop programming


Checking in with your team members and other principals is the heart of your work. But chaining yourself to your computer stops that cold. Everyone loses when you’ve cut off any discussions about quality, progress, or individual development.


Jumping in to correct someone else’s work not only short-circuits their learning process, it teaches them to do substandard work. Pretty soon they only turn in partially completed work because they figure you’ll just redo it anyway. They lose their drive, you lose their trust, and projects start to suffer.


When you move back into production mode, there’s no one available to keep team moving forward. Essential work like status updates, work review, and new project preparation is completely out the window until you pick your head up. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.


Let’s be honest. It feels great to be a hero, swooping in to save a burning building with a brilliant solution. But the cost is just too high. “Quick fixes” often take hours longer, often late or early, and being in chronic firefighter mode is exhausting.


Learn to give feedback well is important. People remember your feedback much longer than you do.

Truths in every software development project

  • Deadlines shift.
  • Clients want more.
  • Team members get sick or resign.
  • The design fails.
  • Someone develops (another!) web framework that’s going to change the world.

What happens when you have regular one on one meetings

  • You’re signaling to your team that you are dependable
  • You have substantially fewer surprises in workflow because you get a peek into future potential issues, the one on one meeting gives them a hook point to communciate with you
  • You have a chance to make genrle corrections by nudging people in the right direction
  • Your managers keep booking over your calendar items

Maybe it’s time to say…

Sorry, I won't be able to attend your meeting due to a conflict. I always keep my calendar up-to-date, so feel free to check my calendar for open time slots.

Biggest challenges team leads face

“Balancing development with being able to delegate responsibility.”
“Balancing management tasks with actual work”
“time management with many different projects needing my attention as an engineer”
“have no time to learn new tech”
“Finding the right balance between manager time and maker time”
“Managing myself!”
“Time management”

You need to get feedback from your team

You need their feedback because…

  1. You’re not perfect, not even close. No one is!
  2. You can’t see where you’re failing (until it’s too late.)
  3. You can’t hear the subtle messages your actions are sending.
  4. You don’t see how you’re coming across to others.

Only you can create a safe environment. Only you can explain why you want feedback. Only you can become humble enough to ask for it sincerely. Only you can care enough to ask repeatedly, in different ways

Why you need to be able to give feedback to your team members

When I could give clear feedback to developers well, wonderful things happened such as…

  1. When I pointed out problems, people fixed their own mistakes. This made them feel good, and showed me I could trust the team.
  2. I stopped having the urge to jump-in-and-make-a-fix-because-it-would-be-quicker-than-explaining-it.
  3. I trusted my team more, and spent less time feeling secretly frustrated. The secret frustration turned into outward, specific corrections, which prevented resentment from building up.
  4. My team trusted me, because they knew I wasn’t holding on to problems, waiting for them to screw up just one more time and fire them.
  5. My team started to relax, knowing that mistakes were expected, and would be met with correction. No longer did they worry I was secretly keeping a list of errors, which I would use to justify firing them.
  6. Annual evaluations became easier, because all the corrective feedback had been given in the moment. This freed us to collaborate about goals, training, career paths and exciting ways to improve our team.
  7. Turnover went down, because people developed loyalty to me.

Learning to give timely, specific feedback well is a key skill of being a great tech leader. Are you seeing the benefits of it?

When you see something amiss, don’t pretend it didn’t happen.

  • Maybe a developer isn’t following the process.
  • Maybe your boss is micro-managing your team.
  • Maybe someone is coming late to every meeting.
  • Maybe someone isn’t paying close attention to code reviews.

Pretending it didn’t happen won’t fix the problem. It will, in fact, send the message that either you approve of the behavior or blind to it. Instead, have a conversation. Say something. Pull them aside and seek to understand the situation. Directly give someone correction that “What I just saw isn’t okay here.”

What your team sees

Your team sees their work, and the company, through you. Your words and attitude carry a lot of weight.

  • When you are negative, they probably will be too.
  • When you are positive, they probably will be too.
  • When you complain, they probably will too.
  • When you are optimistic, they probably can be too.

In short, if you want to see a more optimistic, more positive, more energetic team, start by looking in the mirror.

How to say No Nicely

How to say no nicely pdf

blog comments powered by Disqus

Want to get my personal insights on what I learn as I learn it? Subscribe now!