Guidance for My Staff

I’ve been managing software development teams for about 20 years at this point and have developed 3 primary guidelines.

Don’t surprise me

I really don’t want to hear bad news that you knew about from someone outside our team. I’d rather hear from you that something is about to go wrong so we can figure out the best way to deal with it proactively. Things do go wrong – sometimes caused by you and sometimes not. I’m not interested in fostering a blame culture, rather a “how do we fix this” culture.

This hold true for promises you’ve made as well. If you said you’d be done on Friday and Friday comes and goes, I’m not going to be happy. After all you gave me the timeline. If you come to me on Wednesday and let me know that you are not going to make the Friday timeline for <insert reason> then we can discuss the impact and and how to mitigate it.

Loop me in

One of the primary jobs of a manager is to be the line of communication with the rest of the business, both into and out of the development team. That is why we spend so much time in meetings – either gathering or dispersing information.

My specific guidance is to CC me on any communication that isn’t internal to the team. Emails to the VP of Basket weaving? CC me. Emails to that vendor’s support team? CC me.

Why? Mostly because I don’t want to waste your time or mine asking you if you responded to that email. Since there is a zero cost way to keep me informed take advantage of it. It also lets me know if I should step in should things spiral out of control. Mostly I’m a silent bystander.

Take a moment and think

I have an open door policy (a virtual door these days). I want you to come in whenever you’ve run into an issue. Not that I’m all knowing and can give you an answer, but I’m happy to work it through with you. The mere fact of verbally trying to express the issue will often trigger new thinking.

However, before you come to me I want you to take a moment and think. The saying I use is:

• One idea isn’t a choice
• Two ideas are a dilemma
• Three ideas are a choice

Software development is a nontrivial activity within a company of any complexity, which is why most of us enjoy it. When I hire people I treat them like professionals and expect them to act like professionals. A big piece of that is recognizing that software fits into a larger puzzle and other people depend on us doing our job well. That builds trust, and trust can overcome the occasional bump in the road, especially when there is good communication between all parties.

And that is the crux of the 3 guidelines – communicate and communicate well.