Entries with the tag “management”

When you think of a CTO, what do you see?

Someone gray-haired, steering the ship like the last 20 years? A young, hot-shot that solves every single technical problem and then plays video games to relax?

It really doesn’t matter. I don’t actually picture or “see” anyone.

I can tell if a real CTO is in the room by just opening up my ears.

Sometimes when I get called in to help a dev manager straighten up their team, I face a lot of resistance. But there’s hope. I have a solution!

It seems that every project we run into has missing or out of date documentation. Wikis become stale. Don’t even start me on that out of date README.md file.

It’s almost not worth writing documentation because it gets out of date so fast.

Right?

Conflict seems like a dirty word. After all, we don’t want to have fights at work, right? For managers, reducing conflict seems to be the best choice. But is it?

The title CTO is short for Chief Technology Officer. But what actual roles and responsibilities do they have? Every business is different, so there’s no hard and fast set of rules. However, there are some core responsibilities and philosophies that I believe every person with that title should have.

This advice is based primarily on an in-person team. I’m sure we could make this work with a remote team, too, somehow.

Conventional wisdom says to scope down your initiatives and make small tasks for your team members. It’s best if each can easily work on a single task in a silo, so they can get the project done with the least overlap and delay. But, what are we losing with this methodology?

If you find yourself about to say “we’re a family” to a new recruit joining your dev team, this entry is for you. Managers, you should stop considering or calling your team a family. Here’s three simple reasons why.

Oh, what a scary thought: a manager must always be perfect. But, stick with me here.

What happened to “why?” What happened to make people so afraid of asking this question? Perhaps it’s when all of the 3-year-olds start asking “why” about everything. Why does mommy have to go to work? Why do we need money? Why is the sky blue?

It’s amazing what the internet can bring us, both positive and negative. Sadly, some of the worst people hang out on the internet. They bully, they rage, they say and do horrible things.

A full calendar, hours on the phone, work into the night and a never-ending deluge of emails: the typical Dev Manager’s life. Time is precious and scarce. It’s also very fluid. You’re jumping from thing to thing; meetings get pushed and calls are rushed. It’s not ideal, but it seems to be the only way you can get to all of the things that need your attention.

A colleague once said to me that I’m very lucky I haven’t had to fire as many people as he had. I definitely agree with the fact that my management tenure has not involved many terminations, but I don’t consider myself lucky. I put in work, just like you’re doing, to understand how to manage different types of developers.

When you manage a team, the conversations you have change a lot. No longer are you justifying your own estimates or explaining your coding decisions. Now, you’re responsible for many different estimates, many different decisions, and many different personalities.

Welcome to the New Dev Manager Crash Course! Whether this is your first time managing a group of developers, or you’ve run the gamut a few times, I’m happy you’re here. My goal is to give you some useful tips and direction from my experience managing multiple development teams. I learned a lot of this the hard way, but hopefully you won’t have to!

I worked with a client one time who didn’t like when their employees had side projects. “If they have free time, they should be spending it on our project! That’s why they are salary!”

I’m proud to announce that I’ve launched One on One Coaching at The Dev Manager!

First, to start out, I need to make one thing abundantly clear: This piece is just a bunch of assumptions, generalizations and feelings. I’ve gathered these together after all of my own experiences. That’s why I add the most important auxiliary verb may.

Let’s start out with the basic request or statement:

Interactive coding challenges during an interview are common place these days. The idea is that you’ll get an idea of the type and quality of work a candidate will produce by watching them code during an interview.

As a manager, I spend a lot of time delegating. I delegate small tasks so that I can spend more time adding value to the process and project. The value I bring is my ability to see the larger picture, use my experience as a guide, things like that. If I’m doing too many little things, I can’t do what I’m good at.

I experiment a lot with thoughts and process. I used to be scared of implementing something new because I felt like I was now married to that. Or, if it becomes habit, maybe I won’t want to stop it, even if it’s annoying (how irrational does that sound? But if you’re honest with yourself, you’ll see that happen a lot. If you ever hear “that’s just how we do it” then you’re experiencing it.)

Too often we find a team leader or a manager and just expect they’ll be able to hire new employees effectively. After all, they’re successful, they should be able to clone themselves, right?

Sometimes an employee becomes an ex-employee because they did a poor job. Their quality or output was just not up to par. Otherwise, they backstab, do fiendish things, basically try to screw you. Either way, you can get pretty strong feelings about this ex-employee. Pretty bad feelings.

If you have the question, chances are someone else in the group has it, too. Be brave: get the answer to your question with a by-product of serving others.

I’ve written about mentoring a bunch before, so you know I’m a fan of it. But, there’s another aspect that has been bothering me lately. The questions are simple:

It’s such a cliche by now - “We need a rockstar programmer” or “only code ninjas should apply” - but this choice in your job want-ad is ruining your business. Let me tell you why.

You’ve heard the phrase “The customer is always right” before. I think you’ll find an equal amount of articles online saying that that sentiment is still and always true vs the fact that the customer doesn’t know what’s best for them and they’re not right. (You’ll even hear stories about how some “great” companies like Apple ignore the customer desire and that’s how they became successful.) But they’re not really digging further into the customer relationship.

A programmer’s guide to quality code, great work relationships and respect.

There’s a reason why we want to build high-quality code - actually there are man. But in the end, it boils down to this one point. Good Quality Code Reduces Costs.

Answer this question real quick: What was the most impressive thing you did 2 years ago at work? Did you get the proper accolades for it? Or, possibly more important, did you get a performance-based wage increase or some other reward?

I’ve had a lot of people come to me for various mentoring opportunities. They’ll ask for help, follow up once or twice, and then just disappear. I’m left wondering: Did I make a measurable impact on their lives?

I’ve read the articles and studies about workers creating their own work spaces and I think it’s a great idea. (In fact, the company should too - it increases efficiency by 32%!) But, I never really realized how important it was until recently.

One of the newer programmers on my team asked me the other day why I hired him. I said “I saw you had a natural talent, and have potential.” We both kind of laughed because we knew his skill level at the time was very low. He was not that experienced. But, he had more questions about how I can detect talent and potential versus just someone who has really polished looking code.