1. Always make the boss (customer) look good.
2. Never surprise the boss (customer).
3. See rules #1 and #2.
Making the Boss Look Good
It's simple, really. Everyone wants and needs to look good. That usually means doing a good job - but it also means making sure that others are aware of that good job. It means not trying to pull the spotlight to yourself but instead shining it elsewhere - on the boss for supporting the efforts that led to the success, on the team that did the work, on the support staff that held it all together. Everyone wants to look good and everyone wants their boss to look good. I work directly for the CTO of my company, but he still needs to look good. He's selling ideas and strategies and pushing us in directions that might be different than before. The better I can make him look the easier time he has. So my projects need to work. the technology choices I make need to be wise ones. The staffing choices I make need to work out more often than not. Of course it's possible that you end up working for a maniac and you don't want to make him or her look good. You still need to do it. Even if there's no other reason to do so, it's your reputation you destroy if you don't. Others are watching you, and they will remember. I'm lucky to have a great boss (he's a big part of what makes me like my job). If you are not so lucky, ask yourself if making your boss look good enough to get promoted (away from you) might not be the most cost-effective move you can make?
If the 'boss' is the customer, this applies double. My Dad told me once that people don't do business with companies; they do business with people. Every customer is a person with his or her own needs. In fact, they might be trying to make their boss look good. Regardless, they want to succeed. My job is to help them do that. What do they need? Can I help solve that need somehow, even if I have to adjust my product or service a little? It might make the difference in getting a sale or not.
Believe me, if you make the boss or customer look good - honestly look good through success - you will bask in the reflected glow. A good boss will know that you are the secret sauce and will reward you. A bad boss will get his due, someday, never fear - and the others in your company will notice you and remember. It will help you, even if it's not you getting the direct spotlight for your successes. And if your customers think of you as someone that makes them look good they will buy from you again and again. Your competition will have a huge obstacle to even getting their attention. It's a sort of anti-competition's marketing weapon. And it's just plain being a good person too.
Never Surprise the Boss
Bad news does not age well. It's not wine or cheese - it's rotten food. If you sit on it the smell gets worse and it gets harder to clean up. And it might just infect you with something. If you have some bad news, the best thing to do is to tell the boss or customer about it right away!
Now, this does not mean a knee-jerk reaction and crying wolf. Unless you are entry level you need to apply some judgment to the problem and consider the facts. That may require gathering some facts, and evaluating options. It usually means coming up with a recommendation (and facts to back that up). But hiding a problem, or sitting on it and hoping it will go away - those are recipes for disaster. The boss (or customer) *hates* surprises. We all do (unless it's winning the Lotto or the like). Bad news is never fun and never welcome. But if you can present it while it's fresh, with facts, with some options and maybe even a reasoned recommendation... now it's something that can be dealt with.
The flip side of this as a boss (and a customer) is that if you don't want to be surprised with bad news then you'd better learn to not shoot the messenger. Because if you do then the next time your staff or vendor will likely say "let's sit on this a bit - Greg nearly bit my head off the last time I told him we needed to slip the schedule due to bugs." And what happens? Not what you want. Bad news stays hidden until the last moment and then it's a surprise. An ugly one most likely.
Those are the rules. Not too complex, really. Of course they imply that you are competant, that you can communicate in a mature way, that you will do your best, that you are not personally a maniac of some kind. But those traits are screened for in the hiring process and can be managed (usually). But as a philosophy, if you follow these rules you'll do well.
What rules do you operate by?
[ add comment ] ( 1 view ) | [ 0 trackbacks ] | permalink |
( 3 / 172 )I'm very lucky to manage two outstanding Engineering teams. But it's not an accident that they are outstanding - it was the result of following some basic practices (and a bit of good luck). Here's what I think lead to success:
- Hire people smarter than yourself
- Let the team participate in the hiring process
- Set the bar high - demand excellence
- Don't keep a bad fit
- Share as much information as you can
- Look out for your staff
Hire people smarter than yourself
I'm a generalist and I do admit that I think I'm brighter than average. In a few areas I'm an expert. In others I know enough to be dangerous. But I'm seasoned enough to be completely convinced that there's a LOT of people much smarter than me. I try to hire those folks. And I have to let them be smart - which means listening to them and trusting them. Not blindly trusting them - I certainly challenge them to defend their opinions and designs... but I have to trust. Sometimes I have to make the command decision and over-rule them, but when I do I try to make sure I'm clear in my own head about my reasons. If my ego is involved I'm probably making a bad decision.
Let the team participate in the hiring process
Our interviews last at least 4 hours long. We're up front with candidates to expect that, and if it's going to go through lunch we feed the candidate too (more on that in another post). Each of my senior staff get 45 minutes to an hour with the candidate, and I try to make sure I get coverage across the two teams. We ask hard questions, of course, but we're just as interested in communication skills as we are with coding and analytical skills. There really is only one of two answers from each interviewer: yes or no. The key criteria is 'can this candidate carry his/her weight on the team?' If someone on the team is thumbs down about a candidate I have to seriously agonize if I decide to hire that person. I have done that - and almost every time it did not work out. I usually justified it with the notion that some productivity was better than none but that's not all that true. When it did not work there was usually a clean up of some kind or another that wiped away the apparent gains. As the team gets experience interviewing and seeing the results over time they get pretty good at it. And they gain good skills for their future careers (see about taking care of staff below).
Set the bar high - demand excellence
Mediocrity breeds bugs. Seriously. Excellence is the best antidote. We create a culture where we expect quality code - as much quality as the time allows (sometimes schedule trumps quality). We have formal pair-programming code reviews every week where someone is assigned to look at someone else's code for that week and provide a written summary of what was good, bad and ugly. There's nothing like knowing that your peer - who you darn sure respect and admire because she's smart and skilled - is going to look at your code and share her thoughts with the whole team. We do design reviews (but not as many as I'd like - back to that schedule thing) and try really hard to get the patterns right. We encourage dissent and questions, and when the team members all respect each others skills it really drives a better product.
The important thing here is that while I as Management place high expectations that's NOT what is creating the results. It's the high standards the team is setting on each other that creates the results. I'm just the catalyst. The goal is to create a culture of excellence.
Don't keep a bad fit
It does not take long to figure out who's a bad fit. There's a lot of things that may contribute to the poor fit - performance, personality, external factors - but if someone is not working out you are not doing anyone a favor by keeping them. It's not the lost productivity of that person as much as it's the destructive force on the rest of the team. The culture of excellence and respect I discussed above depends on everyone carrying their share. When the team starts losing that because someone is not a good fit it's the sole job of Management to fix that. It's better for the person to move on to somewhere that they can be a good fit, and it's exactly what will tell the team that the high standards are being upheld.
Share as much information as you can
No one does their best work in a vacuum. A highly functional team must know about the business, the customers, and the strategy for closing the gap between those two. The more they know the better they can make good decisions. They can think 'hey, if I write this class to be extensible it will only take me a few more hours and it would make it easy to add that feature that the account team was talking about maybe needing.' If they are hidden from that information they tend to build things the simplest and fastest way possible - in ways that might not be as easy to extend later.
Some Managers prefer to not bother their teams with this 'extra' information. They think it's just distracting - or in worst case scenarios these managers think that information about the business is their currency of power somehow - as if information control was the key to how to manage. I'm the radical opposite, and I think that the more information a team has the better they perform (if used along with the culture of excellence).
A side effect of this is that I have to be radically involved in the business side of things. I have to visit customers and talk to real users. I have to listen to product management and compare what they are saying to what I heard my customers saying. I have to ask questions like 'what are your pain points and what feature would make that go away?' This increases my work, but I think it's a fundamental part of my job. Without this I don't have the information to share with the team that leads them to a clear understanding of the needs of the business.
Look out for your staff
Most folks can tell if you really have their interests at heart. I make it a point to know what the career goals of my staff are. Do they want to move on a technical track or get into management? Do they want to get a certain certification? Learn a new language? Build communication skills? It's usually possible to find assignments that will build folks towards what they want - and get them the needed exposure to the right folks in other departments in Upper Management - if you know what their goals are. I've promoted heavily from within and worked hard to build the skill sets of my staff through fomal training, paying for books, brown-bag lunches, and practical on-the-job training. Smart, capable people will respond this genuine concern in very positive ways. Today, for example, one of my staff was on PTO but he spent the morning troubleshooting a problem at a customer site. He figured he wasn't leaving town until later in the day and he wanted to see it fixed. We take care of him, and he took care of us. My staff has responded with this kind of professionalism and extra effort over and over. I believe they do it partly because that's the kind of people they are, but mostly because they believe it's a two way street.
None of this is new or unique. I've built these principles over my career both watching good managers and building other great teams (especially the one I built at Quicknet). But I've also read a lot of material, both in print and on the web. Joel Spolsky writes of some of this in his excellent Guerrilla Guide to Interviewing. I just read a short article about how Rockfish Interactive has created excellence. That's a company I'm watching closely.
I could spend 10 minutes and probably track down ten more good examples - but I bet you readers have some favorites to share. I'd sure like to read them.
[ add comment ] ( 2 views ) | [ 0 trackbacks ] | permalink |
( 3 / 140 )
Archives
