Already a member?
Welcome to Brazen Careerist!
Amber Shah is using Brazen Careerist to share ideas. Join now to become a member and start networking with Amber Shah and other professionals just like you. Learn more.
Amber Shah is using Brazen Careerist to share ideas. Join now to become a member and start networking with Amber Shah and other professionals just like you. Learn more.
Managing upwards is really the most important career skill. Managing upwards includes managing expections, thwarting micro-management and getting them to go to bat for you when you need it.
Because there’ll always be someone to manage up. There’ll always be someone above you, unless you’re the CEO. And when you’re the CEO, you’ve got the investors to answer to, unless you’re the private owner. And if you’re the private company, you’re going to need to be able to manage your customers.
When you’re given an assignment, never walk away without knowing exactly what success looks like. What will the end product have? If they want an increase in something, by how much would be considered a win? When does it need to be completed by?
Too many people try to take a little bit and run with it. This can work well for some people, particularly in highly creative endeavors and when that’s really what the boss wants. Even then, though, there is usually something (ie. I want a website design that will get more people to signup for my newsletter, etc) that can define success.
Not having clarity on what success looks like is a double-edged sword. Of course, without knowing it, you could go off on a tangent entirely. On the other hand, if you don’t ask, there’s a chance that your boss doesn’t have a clear picture fo what he wants either. In that case, he’s going to be a tough crowd to please, but asking him can help him pin it down anyways.
Some people resist letting their bosses in on what they’re working on. The idea to be secretive about what you’re doing comes from a general mistrust of your boss. Maybe he’ll say you’re taking too long, but if he’s not even sure how long it’s taking you, he can’t say that. I’m not sure whether this method will work out well for someone who is just trying to get by, but if you’re trying to get ahead, this is a bad idea.
It should always be abundantly clear what you’re doing. In fact, in the software project management style I use, called agile (which in itself is awesome and can be used for other projects) we actually put a sticky note of what we’re working on up on the wall. Anyone walking by knows what we’re working on at any given moment. This actually reduces stress from the boss because instead of having to come bug me about what I’m doing, they can just check the wall. When I work on something else, I’ll change the sticky note.
It’s not necessary to use a sticky note, you can use an online tool or even your status on your chat profile or wherever. Wherever it would be easiest for you to keep it up-to-date and for your boss to find it. So long as you’re effectively hiding this information, you’re basically insisting that your boss poll you repeatedly so that he stays in the loop.
Your boss may or may not know how to do your job. Generally, the more technical your job is, the more unlikely your boss is to be able to do it. As a software developer, I’ve worked for both highly technical people and non-techy folks. My personal conclusion about this is that neither is innately better. It’s best to work for someone who geniunely respects your skill level, regardless of their own.
When you are entry level AND when you are new to a job, there will definitely be a ramp-up period. During this time you may have someone looking over your shoulder while you do your job, figuratively and literally. However, if you’re ever going to move up, you’re going to need to stop letting your boss in on how you do your work.
As an example, there are some software developers that discuss technical minutia with non-technical people. It’s basically the equivalent of a journalist asking his boss whether he should use a semi-colon here or there. You should really already know, but at least be able to find out from some other source than your boss. This applies even if you have a boss who is technically proficient in your work. The entire point of having you is so that part gets abstracted away from your boss’ workload. If you keep letting your boss in on how you’re doing your work, don’t be surprised when he wants to get in your business and tell you to change it.
One thing that can be frustrating for software developers is constant change requests. The traditional project management methods really don’t take into account how to handle them at all. They sort of assume that changes just won’t be requested, which, if you’ve ever worked on a development project, know is a ludicrous idea.
So agile takes a different front and says that not only can you request as many changes as you possibly want, but we’ll really consider every request to be the same. The thing is, we only let you change them 2 weeks out. So for the next 2 weeks, our work is locked in. As it turns out, this restriction is enough to let developers breathe easy, but at the same time gives bosses way more flexibility than they ever had before.
What are your biggest pain points? Sometimes trying to block them can be like building a dam; it takes an incredible amount of effort and water can leak in anyways. What if you could find a way to just accept them into your process, but set other limits, like agile does for change requests?
When your boss asks for something that you don’t really want to do, can you find a way to say yes that makes it more palatable for you? Yes, later. Yes, trimmed down. Yes, for more money. Yes, because business is about negotiation dammit and I can find a way to make this work for both of us!
Bonus points for bringing visibility to your own accomplishments under your boss’s name. Your boss will be happy to be getting credit but it will still be clear who’s pulling the strings since it’s coming from you.
Ready to land that dream job or take your career to the next level?
I understand the article. But I think sometimes there is a loss of balance. The idea of 'learning to manage your manager' sometimes becomes 'deal with it so your manager doesn't have to manage you'.
Here's the deal: Managers are supposed to be better at managing, than their subordinates. That's why they got the job, right?
So they are supposed to be better people persons. They are supposed to be better at management. They are supposed to be better at seeing the big picture rather than the details. They are supposed to be better at organizing projects.
And we're supposed to manage them?
Maybe this works for the ambitious technical person who is anxious to move up into a management role. Sure, give him the lead programmer title and let him manage-up to his heart's content. He'll be happier in that role rather than programming.
But the manager needs to manage the rest of us first.
@Scott I hear you. Unfortunately, management is one of those things that you don't learn in school, but are somehow expected to know how to do. It basically embodies the Peter Principle since if you're good at your job, then you're likely to get promoted to manager, despite the fact that you may have no mangement skills whatsoever.
Actually, my idea of a good manager is someone who doesn't "manage" me, but instead enables me to do my job properly.
For me, the bottom line is that as much as you might say that managers should be good at their jobs, it's so often not the case that we still need to deal with it. Furthermore, even when I've worked for a couple of great managers, there were still times I wanted more of this or less of that, and it's useful to understand how to get it.
@Scott, I look at it this way: someone needs to manage. If your manager isn't, then you need to.
But in truth, you aren't managing the department in his or her stead. In fact, I think "managing up" is something of a misnomer. What you're really managing is yourself, and how you communicate.
@Kate Sounds good. Reminds me of the old phrase "You teach people how to treat you". If you're not doing -anything- then the message is probably "do whatever you want" which I'm guess is NOT actually what people intend to say.
My comment is a reaction to your original post as well as Scott's comment and your subsequent response.
First of all, I completely agree with your original premise that managing up is a critical skill - particularly in a project management role such as yours. And I also agree that "how to be a great manager" is not taught in school - particularly in technical fields such as software development and engineering - and that far too many organizations thrust previous individual contributors into management roles without adequate preparation, training, and ongoing support.
Second, the primary role of a manager is to get work done through others. His/her role is to set and communicate clear expectations and priorities, provide ongoing feedback to you and your team about your collective performance, to be clear about the kind of supervision she/he will provide, and to help you develop. "Managing up" means getting clarity about expectations and changing priorities, clearly communicating progress and problems so the latter can be addressed on a timely basis - managers hate surprises - and as you say, being clear on what you need from the manager to be able to get your work done - like maybe interceding for you and your team on some issue. And your post generally addressed these aspects of managing up.
What really troubles me though is your comment about withholding information on how you are doing your job. When I was a practicing manager, I was very clear on "what results" I wanted to see and gave my direct reports a lot of flexibility on "how" they got those results - with a some clear parameters. I would check in with them on how they planned to get the results. As long as the "how" was ethical, legal, and would not create problems because of some issue they were unaware, I would let them go ahead even if I would take a different approach. I would give some feedback on things to consider though as part of the teaching aspect of managing. However, if a direct report refused or obfuscated how they were going to complete their work, I would treat that as a HUGE red flag. I actually fired someone for this behavior because it turned out they were hiding illegal activity. If your intent is to keep the manager from micro-managing you, maybe the conversation needs to focus on what the manager needs to know to be able to feel confident the results will be achieved.
@John I appreciate your insights, thanks for commenting. For me, it's not that I would ever intentially obfuscate how I'm doing my work, but there is a big difference between staying quiet and volunteering that information.
Perhaps I also have a different view since I am in a technical field. For example, non-technical people like to ask us to do the fastest solution possible, but then be upset when there are bugs to fix later. Early on in my career I felt torn, but now I draw the line and don't let non-technical people, even managers, dictate the quality of my work, even if it's going to take me longer, they'll just have to wait. This is one of the times where the person doing the work knows better than the manager.
Also, I often run into a situation where non-technical people try to wrap their heads around a complex technical problem. It ends up being stressful for them and even though they think they are helping, it doesn't. As a developer, I promote practices that push for transparency and quality, but only within the technical team. Expecting or even allowing a non-technical person to play a role in technical quality is just a recipe for disaster.
Amber,
Thank you for your thoughtful reply and I understand completely the technical/non-technical polarity that needs to be managed. I am also VERY aware of the pressures of the IT world and know that non-technical people can often have unrealistic deadline expectations. I was simply trying to raise a flag of caution more generally.
From the point of view of a non-technical manager, they are accountable for a specific result - e.g., a new system. And they are getting pressure from above about deadlines etc. from other non-technical people. What increases the stress of non-technical managers is the lack of understanding of the technical process needed to get the results for which they are accountable. In short, they need to trust a process they don't understand.
What you have going for you is a track record of high-quality, bug-free software that is easy to maintain. And that credibility that you have is how you help the manager trust you. What really helps a non-technical manager is knowing how he/she can buy you the time you need to do your work. So in this case managing up is helping them communicate upward to their manager as well. So they need your help here how to do that.
"Expecting or even allowing a non-technical person to play a role in technical quality is just a recipe for disaster."
Here's the problem with that. The end users of the system and the majority stakeholders in the project's success almost always are non-technical. The systems you're putting into place are for THEM, not for IT.
Implementing something like a new CRM system, ERP system or something that is vital to the company, yet is being operated by non technical personnel, is always going to have these issues.
If the CFO (for instance) feels that he and his people are being cut out of having any input in what is being implemented, and how it's supposed to work, especially if the system is for their use, you're going to have bigger and more immediate problems than merely keeping non technical people out of the technical process.
Quote from an old CIO:
"Fast, cheap, or good. You're only get two out of the three. No exceptions."
@JRandom42 You're right about needing the support of non-technical folks, which is exactly why managing upwards is so vital.
Non-technical folks trying to get involved in the technical details is sort of like saying you should set the quality standards for doctor's performing operations just because you can sew a hem. It's not just ineffective, it can actually be harmful.
Of course they will be involved in the process, but it's important for us technical folk to set appropriate boundaries (without them seeming like boundaries to them)
@JRandom By the way, I like the quote. Seems true to me.
My original comment may have been a bit strident, so I'll clarify my opinion.
I have to often seen the suggestion to 'manage-up' be used as an offical excuse for lazy management. Sometimes it's also presented as 'empowering' the employees, by pushing down responsiblities to the employees that should be the manager's.
I fully understand that the employee needs to take their manager's needs into consideration sometimes. But it is primarily the manager's responsibility to take the lead in everything regarding their employees. After all, the manager is on the hook for their employee's work.
One example would be in the area of communication. I feel that it is the manager's responsibility to initiate communication with the employee on a regular basis. It's not good enough to say "come to me if you have any problems" and go away for a month. The manager needs to have regular meetings, conversations, status updates, etc. Then if the some unsusual situation comes up outside of these communications, then employee can take the initiative go to the manager. But if the employee has to take to initiate all or even most communications, then something isn't right.
The point is that there needs to be some baseline management already going on. And unfortunately, too often the idea of 'managing-up' is used as an excuse to avoid that.
Amber,
I remember being involved in settling a big blowup in a Finance project to streamline operations. The Senior Accountant and the Project Manager were almost coming to blows over the data format.
Finally, the Senior Accountant, almost ripping off his tie off, shouted at the Project Manager, "Why won't we accept this data format? Because the SEC and the Feds won't!"
The Project Manager countered, "Well, why didn't you say so?"
And the Senior Accountant shouted, "I told you that 6 months ago, during the planning sessions! And you said, "Trust us to do it right". Well, it's NOT right, and I can throw an aircraft carrier farther than I will ever trust you again to get it right!"
Needless to say, the Project Manager was replaced, the project went on to be fully implemented 3 months late (and several hundred thousand over cost), and the internal IT department was never trusted again with another project of this scope.
@JRandom And really, that PM shouldn't be trusted, as he clearly wasn't listening to the customer. I'm just wondering though, if the company was willing to trust outside consultants, but not their internal IT department, why didn't they just hire the smart consultant guys into their internal IT department?
This was supposed to be the flagship project that would literally put the company on the bleeding edge of finance automation, and was the first real project of this scope for at least 20 years for the IT Department. And it was all done in-house.
There were plenty of sharp developers, designers and engineers. But the project manager, who was pretty sharp (the "wunderkind"), had a vision of what it was supposed to do, what it was going to look like and how it was going to be implemented and he was pretty ruthless in gathering the "faithful" to see his vision.
As for not hiring smart consultants, within 2 years, that's all they did, because all the IT functions had been outsourced, essentially by decree of the CEO and the Chairman.
Manager must be easygoing and kindly because they will be manage a head system in one management.
Email
Print
