How should I approach a 'One on One' with my boss's manager when there are issues with the project?

Question

Here is my problem. I have recently shifted job and I am mainly into computer programming. We work in a framework which is almost 75-80% complete. And I have been given a task to add something more to the the framework. Now I am already seeing a lot of code smells in the existing framework code. I can easily put something quick and dirty and complete my assignment and impress my boss's boss who has scheduled an one on one with me. The problem is that the existing code/framework was mainly written by the person who is now my direct boss. So what should I do? Should I talk about my concerns regarding the existing codebase to my super senior or should I just keep quiet? I am thinking about the implications because if I convey my concerns definitely my super boss will have a word about it with my boss who in turn may take it personally. What should be the right strategy for me in this dubious situation?

P.S: This will be my first introduction with my super boss and I do not want to come across as a cry baby. But at the same time I understand that these points are important and should be raised before it is too late.

Answer 1

I would suggest that, if you have the time before the "big meeting":

1) Do a thorough (or at least not too shallow) evaluation about the code, to properly identify the blocks that "smell bad" in your code, identify the reason why it is bad, and how can it be "fixed" (or why it must be fixed). Just telling your boss "it's bad it stinks" is a huge NO-NO, but it is also bad to say "it is bad" and not being able to assertain a good reason why it is bad.

2) Go to your boss (direct boss) and address such concerns about the code. It would be a severe breach of trust if you go above him without his knowledge, and can be taken badly if not discussed first with him, at least to give a "heads up" about the issue. If it is a team development, and you were the first to take notice, you should bring it up in a group meeting, but not before talking to your boss.

3) If such meeting goes sour, you can address your boss' boss and let him know about the problems, but do it in a way that addresses the problem at hand, without diverting into a "blaming game", just provide your insights about the code, and if asked, prepare a "how would you fix it" little schema.

Answer 2

When you joined or took over this project you should have had this discussion with the previous developer (your boss). If he's only had one initial pass at this framework, of course there is plenty of refactoring to do. This probably isn't going to be a big surprise.

You have the advantage of hind-sight, so don't assume your boss is a terrible programmer because of the current status of the code. No one writes perfect code or anything else in the first draft. They hired you to come in and take things to the next level. If given enough time, your boss could probably clean things up.

On the other hand, if your boss suggestions you ignore the code because "it works well enough" you could have a problem. This could make your job tougher when you try to debug and add new features (Unit Tests?). Not everyone is big on iterations, clean code, or the new cliche - elegance.

Find out the score before you try and pick the winner.

Answer 3

An extremely timely answer was posted today to a LinkedIn blog written by Steve Sinofsky, who was President of the Windows division at Microsoft until a few months ago, titled Benefitting from skip-level 1:1s - tips and pitfalls. About half of it is for managers conducting the meeting. Don't skip this: read through it so that you can get a sense for what your manager's manager's goals in doing this 1:1 with you might be.

The other half of the blog post is for you as the individual contributor who's going to this meeting, and there's a lot of wisdom in there, starting with this:

A skip-level 1:1 is a great time to offer your perspectives on what is going well and not. There's a fine line between offering up all the potentially bad news and sounding like you're setting expectations, and polishing up all the potentially good news and sounding like you're showing off. You have to be the judge.

I think that this is true for any meeting. You have to be able to identify what is going well as well as what isn't going well. For example, you could say, "it's good to work for a manager who knows the code as well as my manager does", or "I think we've done a good job of getting the first version of the framework done, and I hope that we'll have the time to go back and ensure that the code's architecture will stand up to [something important: scalability, increased performance requirements, etc -- pick an area of concern from your code smells]".

Sinofsky also makes the point that you should never make news in this type of meeting. This meeting is never the first place where you should raise a concern. He closes off with this:

Above all, make the most of the time to make sure your skip-level manager is familiar with you and your work in a neutral and constructive way.

Answer 4

I'd advise a heavy dose of tact and honesty here, and it that needs to start with a conversation with your boss about being allowed to alter the existing framework. Again, let me state to do this tactfully! Here are some ideas that might work:

• Don't use many negative terms when referring to the exisiting work.
• Frame all your suggestions as changes that might make updates or maintenance easier for you in the future or that might make it easier for other new programmers to pick up the project later. You'd be the expert here since you're the first to have to do that.
• Make it clear that you are running these ideas past him for approval and to get his expert opinion.

Be sure to request some sort of official project so that it doesn't look like you are goofing off or are making slow progress on your other project(s).

Meeting with your Boss's Boss - again tact and honesty.

Part of an employee's unofficial job description is to make your boss look good. You should do your best to do this if you honestly can, but your boss's boss needs the truth to make the best decisions. Make sure anything negative you might say about the code or the project has been brought up with your boss first and report based on what your boss's decision was. Again some things that be useful:

• Try to determine the underlying goal of the meeting as early as possible, if your boss's boss is looking for dirt on your boss you need to decide if you really want to be the source for that and act accordingly.
• If it's a get to know you meeting then don't dwell on this stuff and try to make a good personal connection.
• Try to make your boss look as good as you honestly can, but make sure you don't sell yourself short to do it
• Try to act like your boss is in the next room listening in.

The chain of command has been bypassed, which is something a manager can do a lot easier than an employee, what I'm suggesting is that you act (to the best of your ability) like it hasn't and loop your boss in before (and probably after) the meeting with your boss's boss.