I preface this by saying I believe I know very little about management. I am a software developer who happens to also manage, not the other way around.

Recently, I have been on a Don’t pass-the-buck kick. What do I mean by this? Imagine the following scenario.

Chris the CEO decided that manager Max’s team needed to stop working on widget X and start working on widget Y because it has more business value. Max knows his team is already halfway through widget X and really loves working on it, unlike Y which is not started and the bane of their existence. But, Chris the CEO knows what is right for the business and Max does what he asks.

Max then goes and tells the team ‘Team, Chris is forcing us to switch from X to Y. I know you love X and I fought to keep it, but he is the boss and we have to do what he tells us’

What’s wrong with this story? Manager Max passed-the-buck. Managers serve two important roles in regards an organization’s structure.

1. Advocate for their team – This is easy. Manager Max fought CEO Chris for X instead of Y.
2. Face of the organization – This is hard. Manager Max could have explained why Y was more important. He could have been the bad guy to his team, but he wasn’t.

Being the face of the organization is hard because it involves hard conversations. Hard conversations suck. But if they aren’t had, worse can happen. Team’s need to understand why Y, in order to connect with the mission of the organization. They also need to have a conversation about Y, no matter what the outcome. Otherwise, the manager is basically saying their opinions don’t count.

I think passing-the-buck is something prohibits many managers from becoming leaders. I am absolutely guilty of doing it, but I realize its detriment to me, as well as my team.

Leadership is ultimately about creating a way for people to contribute to making something extraordinary happen.

(PS: The phrase passing-the-buck has a very interesting history)

One of the hardest tasks I have as a manager is empowering developers to make their own decisions. I like to think I do it pretty well, but I know way too much about a lot of applications. Sometimes I find myself defining how something should be done instead of just what should be done. For developers turned managers, I imagine you might feel the same way. What it really boils down to is understanding when to step in and when not to.

Stay out of application design meetings. Most managers that have been in an organization for a while have a good idea how something should be done. This doesn’t always mean they need to express it to their developers though. Staying out of these meetings allows leaders to step forward and drive the conversation. With a more senior person in the room, they may stay silent. Most good teams will leave a design meeting with an awesome plan and a list of questions for me anyways.

Steer developers away from pitfalls. In the above, I mentioned staying out of design meetings. It doesn’t mean you should be ignorant to the design of an application or feature. Get someone on the team to give you a summary, and recognize any concerns you have. You shouldn’t let developers do something that you know has a high chance of failing because you have experienced it. Plus, you are a domain expert, your guidance may shine light on something they didn’t think about. The important thing about giving feedback is it is after they have an idea of how to do something. Then, you are not defining the how but the what if.

Influence through teaching. Good code has certain traits. Easily testable. Decoupled. Inversion of control. Etc etc. Instead of defining how they apply to a given scenario, teach developers why they are important. It is one thing to explain inversion of control and dependency injection containers, it is another to define a class diagram for a given feature. Let them figure the latter out on their own.

Let them go out on a limb, every now and again. Management has a lot to do with trust. Once you trust a team, it is alright to let them go out on a limb every now and again and do something you aren’t 100% comfortable with. As I get further from day-to-day development, this happens more often. It is a good thing actually. I don’t know the specifics of certain technologies my teams are using anymore, but I have teams embracing them. Letting them do it is a huge step away from the how and into the what.

Managers that define the how prevent leaders from stepping up. For a team to feel ownership of an application, they must be empowered to make decisions about that application. This really starts by helping define the outcome and not the steps to get there.

Good developers have a tendency to learn, which creates a problem. Everything they did yesterday, they want to rewrite to be better. They are NEVER content with their code! To make things even harder, most developers are pessimists and always make the current state of any application worse than it really is.

While these are actually great traits for their role, it can be easy to let developers sell themselves short and miss working on something great in favor of improving the old. Managers have to continually challenge them and make sure they are working on things that will help them achieve greatness.

How do you find the balance?

• DO fix things that are broken.
• DON’T sacrifice quality.
• DO follow the boyscout rule. If you are making things a little better as you go along, you will keep the ship afloat.
• DON’T rewrite things if you absolutely don’t have to, especially if they aren’t broken.
• DO push developers to accomplish more than they think they can, while being realistic.
• DON’T worry about scaling too far in advance. An application has to scale for a few months after launch, but resources are better suiting building things to entice customers, and therefore create a need to scale, instead of scaling before the need. (Just make sure you know when that need is hit)
• DO eliminate all the waste and make sure your developers are truly working on the most important things.
• DON’T wait for perfection. As Dharmesh says, if you aren’t a little embarrassed of the features you are developing, you waited too long to release it. The internet is too fast paced to wait a second.

In summary, make sure you are challenging your developers and pushing the envelope on the things they are working on. Developers have an insane desire to make something perfect, even when the business case may not always be there for it.

In war, trenches are a fortified position soldiers use to defend against enemy attacks. They help keep soldiers safer than they would be out in the open, making enemy attacks much easier to fend off. The problem with trenches is they don’t allow progress. You can’t just move a trench, you have to get out, move forward, and build another one.

Software developers often have a similar, albeit less deadly, problem. The enemy is all the inefficiencies that get developed over the course of a software development project. In order for the project to survive, it is important for developers to get in the trenches and work through the inefficiencies to keep things afloat. In order to win, the developers have to eliminate the inefficiences, which means getting out of the trenches and making progress on the root of the problem.

How many times have you dealt with customer support about a minor bug before you fix it?

How many times have you manually built and tested your application before you automate it?

How many times have you spent hours doing deployments before you make it push button?

Most inefficiencies only hurt the long term success, and not the short term. How do you eliminate them? Managers need to be in the trenches with their people. They may not do any fighting, but they have to feel the pain and understand the problems, otherwise they won’t help their team move forward.

What are your teams fighting with in the trenches?