Have you ever found yourself wanting to make a major shift – in skills, in roles, in relationships? One of my good friends, Jimmy May (Blog | Twitter), accomplished a set of major career and lifestyle revisions including relocating to Redmond, taking on a huge new level of job responsibility as part of the Microsoft SQL Customer Advisory Team, and achieving the noted accreditation of Microsoft Certified Master.
Jimmy and I were chatting about undertaking major life changes like these and, as is often the case, his thoughts were too good not to share. Be sure to explore these excellent career development resources. So here were some great pointers from Jimmy:
Let me know what other resources you enjoy for professional and career development!
And if you’re really interested in developing your IT leadership and management skills, I encourage you to attend my Leadership Skills for IT Professionals seminar. I’m presenting this full-day seminar in Dallas at the SQLRally on May 8, and in Louisville at SQL Saturday 122 on June 19. Hope to see you there!
I’m being a little bit incendiary with that title. Many IT pros grow into very good managers. But it almost never comes naturally. It takes hard work and many hard won lessons before most of us ever achieve a degree of skill and comfort with managing other people. Thinking about moving into management? Help is here!
I’ve been spending the past several years turning the lessons I’ve learned as a manager into a set of courses for IT professionals who want to make the leap in to management. I’ll be presenting some of these lessons as full-day seminars. I hope you can join me! Details below:
Some of them I learned (fortunately) through reading, training, and extensive coursework before I ever experienced them in person. Some of the lessons, I learned through a kindly mentor who helped me see problems coming just over the horizon. And some of the lessons I’ve simply learned the hard way. Maybe your career path is headed in the same direction as mine…
An Oft-repeated Career Path…
Here’s how mine went, and it’s a rather common refrain among IT pros. It goes like this – you’re outstanding at your IT job. You excel. You have a lot of credibility. Every few years, you get a promotion. But eventual, your boss (or your boss’ boss) tells you that you’ve topped out as a technologist. They simply can’t give you any more raises. And there are no higher level technology jobs you can get promoted to. You couldn’t even get a better job at another company. Ah, but there’s more to the corporate ladder than just IT. There are all of those juicy management positions that =DO= offer potential for more raises. So you say to yourself “Why don’t I just jump over to the management track? I excel as an IT guru. I can do that management stuff easily. In fact, I’ll be better than any of my bosses ever were!”
…Leads To Oft-repeated Mistakes
But if you’re like many IT pros, it starts to sink in that all of those skills which made you ‘the awesome’ as an technologist are =NOT= transferrable to the management work you’ve now got on your plate. Successful IT people, by their very nature, often succeed because they enjoy “the machine” more than personal interactions – and that’s what good management is all about.
Here are some common behaviors I’ve seen from IT people once they get into management that can cause lots of problems.
Answering a simple question via email, Twitter, or IM when the person asking the question is in the cube a couple strides away.
Spinning up a long back-n-forth email thread when a phone call could settle the issue in 10-20 minutes.
Spending many hours on research to justify a recommendation for an important decision, sharing the research with other stakeholders (via email, usually), and then being surprised that no one supports the recommendation.
Failing to convince the boss into spending money on important ideas, like training or tools, or increasing headcount.
Even after extensive interviewing, hiring someone whose a poor fit for the team.
Thinking “We’re way behind on our projects, so I’ll just spend today hip deep in the technology helping the team get back on track.”
Puzzling over why team members are demotivated and unproductive, or that they are motivated and productive but to their own purposes.
Can you name a few more? Add a comment!
But Why?
Problems like these are simple issues of human nature. We all, naturally, try to do things according to our preferences and experiences. But their two very consistent built-in preferences of IT pros that these mistakes keep happening again and again are:
Choosing the computer interface over the human interface: We got into IT because we like computers. We thought of them as at least a little bit cool. As we spent a bigger percentage of our day clacking on keyboards, clacking on the keyboard became our preferred way to interact with other people. In fact, as IT people, the computer is our work. But when we become managers, the computer is, at best, only a tool for our work of managing people and, at worst, an outright impediment and obstacle to our work. Many problems in leading teams have their origins in choosing a computer-based method of communication when another form of interperson communication would be quicker, yield better results, and improve team interaction.
Smart is as smart does: A very common element of human nature is for people who are successful and smart to believe that success and smart applies to pretty much everything they do. In my own family, I recall family reunions where one of the more successful cousins, who was in the insurance business, enjoyed giving everyone else advice about personal finance, stock and investing, politics, religion, parenting, animal husbandry, and who-knows-what else. He basically believed that because he’d done well in other areas of his life that he was right about everything he had an opinion about. Ah, but pride comes before the fall, does it not? And of course, he was tripped up several times by his own limitations. We see this same sort of pattern repeated when the IT Pro begins to manage a team in the same way s/he managed her IT resources. The only problem is that machines deterministic. They yield consistent results when provided consistent inputs. People, well, we could say that people are non-deterministic, but it might be more accurate to say that people are plain ol’ chaotic.
Of course, I’ve just touched the tip of the iceberg with these two points. I’ll be talking a lot more about this in future posts and fixes for these common issues.
Comments? Thoughts? Experiences?
I’d love to hear your own experiences either as the IT pro seeking or working in a management role, or as an employee watching another IT person learn the management ropes. Add a comment here or drop me an email.
Back when my day-to-day duties included database administration work and enterprise architecture, I became rather obsessed with the idea of operational excellence. I read everything I could on the topic. I made a list of favorites, which became somewhat shabby over time, as I dog-eared important pages and scribbled notes in the margins. (Perhaps that list of favorites might, in and of itself, make a good blog post). Fast-forward a decade and I’m still mightily interested in operational excellence for IT organizations. It’s just that so much good material is available for free on the web.
Here’s a run-down of several useful documents and downloads to improve overall operation performance for those of you in a Microsoft-centric IT organization:
Microsoft Operations Framework
Microsoft Operations Framework (MOF) version 4.0 guide is practical guidance for IT organizations. With the release of version 4.0, MOF now reflects a single, comprehensive IT service lifecycle—it helps IT professionals connect service management principles to everyday IT tasks and activities and ensures alignment between IT and the business.
Infrastructure Planning and Design
The Infrastructure Planning and Design (IPD) guides are the next version of Windows Server System Reference Architecture. The guides in this series help clarify and streamline design processes for Microsoft infrastructure technologies, with each guide addressing a unique infrastructure technology or scenario.
Microsoft Baseline Security Analyzer 2.2 (for IT Professionals)
The Microsoft Baseline Security Analyzer provides a streamlined method to identify missing security updates and common security misconfigurations. MBSA 2.2 is a minor upgrade correct minor issues and add optional catalog support.
Security Compliance Manager
The Microsoft Security Compliance Manager provides centralized security baseline management features, a baseline portfolio, customization capabilities, and security baseline export flexibility to accelerate your organization’s ability to efficiently manage the security and compliance process for the most widely used Microsoft technologies.
SSWUG.ORG’s virtual webcasts will prepare the “Accidental DBA” for patterns and practices they will experience in their role as a database administrator. I will provide easy-to-understand insights and realistic examples for professionals who have not had any formal DBA training. By the end of our four-part series, you should have the information needed to get up to speed on database planning, administration and performance tuning basics.
Session Descriptions
In the first session, you will see what is needed to fulfill the role of a (Database Administrator) DBA by learning more about what is typically expected of administrators and where the bulk of the work is done. Regardless if you are a draftee or volunteer to the position, the information applies to anybody wanting to better understand and fully own their title.
Over the course of the second session, you will find out why it is important to grasp some of the tips and tricks that DBAs have practiced for many years. I will emphasize about the need for documentation, testing, automation, sharing experiences and continuing your education.
During the third session, you will understand the reasons why the DBA is the sheriff in town! That’s why it’s important to know what you’re dealing with in your departments and inside your databases. I will explain how to inventory, determine what is not your responsibility, talk to your stakeholders, learn the business cycles and tackle important tasks.
The fourth and final session will emphasize the four essential skills needed to survive and excel in your database administration position – Communication, Troubleshooting, Benchmarking and Automation. I will explain how to leverage these abilities toward increased job security and professional successes.
The 2011 PASS SQLRally is just about one month away and it’s high time I highlighted some of the important things you’ll be hearing about in my precon seminar Leadership and Team Management Skills for the IT Professional. Just to set the context, many of us IT people got to our lofty career positions because of our keen use of technology. It takes a lot of smarts to get where we’ve gotten, but they are a very specific set of smarts that can’t always be used in every business setting. And, since so many of us have topped out in our potential salary as long as we stay in the trenches and the only do technology work, a lot of us are starting to eye those middle manager positions so that we can continue to see our career grow. The only problem is that all of those skills that enabled us to become top tier technologists don’t transfer into the management arena.
I’ll be teaching a wide variety of soft skills and specific management checklists to help you survive those early transitional days. And if you’re not a manager? You’ll still want to attend because the wide variety of communication skills we’ll cover will help you stay on top of many other real life situations, from leading the local Girl Scout troop to taking a role on the local PTA organization.
You can read the full and pedantic session description at the link I provided up above. But here’s a list of Five Funny Things You’ll Hear in the Precon:
“Here’s where we get out the whips and chains…”
“In this section, we’re going to learn how to manage our managers…”
“And then I was, like, OMG. And she was, like, LOL. And her cousin was, like, ROFL. But then I was, like, meh…”
“Darth Vader would be proud…”
“The beatings will continue until morale improves!”
And one bonus:
“That’s what she said…”
Did I put these in context, heck no! But it’s a fun session, with some practice labs and LOTS of content to help you make that transition from full time technologist to part- or even full-time leader!
In this vblog entry on www.SQLServerPedia.com shows SQL Server expert Kevin Kline discussing his views on how to be both efficient and effective in your day to day and career – aimed at the SQL Server professional, but good for anyone.
I’m frequently asked the following paraphrased question:
I’d been happily plugging away in my job as a {DBA/Dev/Terminator/Warp Drive Engineer} for several years, when I applied for the manager position. I was surprised and thrilled when I got the job! But now that I’ve been in the job for a while, I find that no one on the team is thrilled with me. I know that I made a lot of changes. But they were all for the good of the team. What should I do to reconnect with my team and rebuild my friendships?
A common theme in this series, “Plays Well With Others”, is that the skills responsible for your success as a database professional have little in common with success as a leader and manager. And this scenario is a classic example. It’s especially important to our situation because the solution to this problem is entirely people-oriented and has nothing to do with all those great SQL Server skills you’ve developed over the years.
It's not always comedy
First of all, if you haven’t already, avail yourself of the excellent and time-tested Blanchard’s Leadership and the One Minute Manager as well as The One Minute Manager, both by Kenneth Blanchard. Management and leadership books churn through the bookstores as quickly late night talk shows on NBC have lately. But this book has proven its worth over the years and its advice still holds up well.
Next, recognize that most management hassles can be defeated or at least deflated by publicly getting in front of them. In a sense, the best way to solve this kind of problem is a bit of proactive damage control. So instead of launching into a bunch of new initiatives and changes for the team (especially the kind that reduce a former teammates’ power or privilege), announce that you’re considering a bunch of changes. You don’t have to be specific about your plans, but don’t be intentionally vague or evasive either. Further explain that some of the changes may be uncomfortable, but you’re convinced they’ll make the team much more productive and return greater value to the enterprise.
Ask everyone on the team for input and ideas of their own within the next X number of weeks while you formulate your plans. It’s very possible that you might 1) get ideas from team members that exactly matches what you’d planned to do, and 2) get new ideas you never thought of but would like to add to the mix or even put higher in priority. Be sure to thank everyone who steps up to the conversation (or email thread).
Now, it’s time to book some one-on-one time across the team and have the “tough talks” well in advance and in private with those who might be on the losing end of your changes. Also, invite suggestions about how to best go forward. You might be surprised by their team spirit. By treating everyone with empathy and dignity, you might turn one of these potential grumblers into a reliable “wingman”. On the other hand, arguments are quite likely so explain that the changes are non-negotiable, but reiterate their contribution and value to the team.
By handling this situation with foresight, you send several messages. The first and strongest message is that you are the leader. This might not be comfortable for your friends or even to you. But it’s extremely important to establish this role early on. And by handling the situation with dignity, you demonstrate that you have credibility, which makes strengthens you in a sort of positive-feedback loop.
If it’s too late to establish your “street cred” and you’ve already fumbled the early stages of the transition to leadership, you can still recover. But as the old saying goes, an ounce of protection is worth a pound of prevention. Usually in a situation like this, you should implement a goal-setting and planning session with the entire team. Explain that the objective is to collaboratively define the goals and objectives of the team and to adjust team responsibilities, processes, and duties to best accomplish those goals. Personally, you should remember the purpose of the meeting is, primarily, to get everyone on the team knows buy-in to your vision of “success” for the team and, secondarily, firmly establish your position as leader. It might take as much as half a day to hammer this down.
Prepare ahead of time. Make sure that your changes mesh with management’s goals for your team. Ensure that you and YOUR boss are on the same page about what characteristics would mark a team as “successful”. If you have some extremely strong willed team members or are expecting outright conflict, you may need to conduct your goal-setting session as a one-on-one series of meetings rather than a single meeting for the entire team. Schedule a conference room (with a white board) and appoint an official scribe to record the details of the meeting. Encourage a lot of brainstorming during the meeting. Make sure to discuss these topics:
What are we here for? A comprehensive list of team goals that characterize the team as “successful”. Be sure to project top management’s view of success to the team since you might be the only one who fully understands what management expects, plus you can contradict any false notions held by team members.
What do we do daily? The bulk of daily duties and processes performed by the team (before your changes) put in place to try to meet the goals in topic 1.
What could we do better? List any changes you put in place, as well as solicit ideas from the team. Accommodate good ideas from the team, but not at the expense of meeting the enterprise goals. Explain to the team that the goals of topic 1, as well as duties and processes of topic 2, are a sort of “contract” with the enterprise. These are the things that the enterprise uses to evaluate whether you’re all successful or not.
What did we decide? Explain that, as the leader, you’re interested in maximizing the contribution of the entire team. This might mean that the best solutions for the team are not always what each individual prefers. Reinforce that everyone on the team has part-ownership in the team contract. Express confidence in the team that they can make the changes especially effect and thank each one for their contribution and efforts.
At the conclusion of the meeting, you should now have buy-in from everyone on the team and a strong consensus on expectations. Going forward, you can use the “contract” agreed to by you and your team as the basis for evaluating performance and, if needed, for correcting underperformance.
So, after all of that, does that mean you’re still the buddy of the guy in the cube next to you? Chances are good that you and your cube-mates can stay buddies, if that’s your main goal. Just be mindful that most peer-to-peer relationships do change when one of the peers is promoted to be the boss of the other. However, you can avoid these relationship issues by clearly and explicitly defining everyone’s role and then getting explicit, verbal (or written) confirmation that you and your workmates are in agreement.
One fall semester many years ago, I was a university freshman. Actually, I was anything but “fresh.” I was dumb enough to think that 8 a.m. was a wonderful time to attend Economics 101. After staying up until the wee hours most every night, the “dismal science” took on more than one meaning as I set my clock just early enough to get to class on time. Along with 30 other very naïve classmates, I staggered into class and did my bleary-eyed best to focus on the lessons at hand. There were lots of Greek compound words and lots of graphs.
Graphs Don't Always Help Explain The Situation
I learned, for example, that the word economics derives from the Greek “oikonomikos,” which means, approximately, “death by slidedecks” and, specifically, “house” (oikos) and “management” (mikos). I barely survived the experience and never took an 8 a.m. class again. Imagine my surprise, then, when a lesson I’d learned (and promptly forgotten) all those years ago jumped back into my consciousness late last year. [READ MORE]
Last week, I talked about one of the worst type of management scenarios to work under – the micromanager. Now, let’s take that conversation from the “Dark Side” into the light to talk about great leaders.
To say that Dr. William Cohen knows a few things about leadership is approximately the same as saying that Moby Dick was a fish. Not only was Cohen a former Air Force major general, university president, and business leader, but he has many degrees (including a PhD) and even holds several engineering patents. One of the many books authored by Dr. Cohen is the 1998 Best Business Book of the Year, The Stuff of Heroes, also considered by many to be one of the ten best leadership books of all times.
If you’ve ever had a desire to lead, I recommend reading this book. But even if you never read it, Dr. Cohen’s lessons are intriguing. Even a quick list, like I’m presenting here, offers a lot of practical advice. This summary can’t do Dr. Cohen’s material justice, but here are the main behaviors of extraordinary leaders, as revealed by his research:
Maintain absolute integrity.
Know your stuff.
Declare your expectations.
Show uncommon commitment.
Expect positive results.
Take care of your people.
Put duty before self.
Get out in front.
A common cliché these days is that someone is “a born leader”. The better adage is that leaders are made, not born. Consider the eight behaviors above. Which of those behaviors require innate ability and are not something that can be learned? None of them! In fact, closer inspection of the eight behaviors of excellent leaders shows pretty clearly, at least in my mind, that each behavior results from a conscious decision on the part of the leader to behave in a certain way.
In effect, great leaders are constantly mindful that they are scrutinized by the teams which they lead, are committed to those teams and the results they deliver. Whereas poor leaders spend lots of time thinking about what their teams can do for them, great leaders think about what they can do to make their teams produce better results.
We could spend more than one article on each of these eight behaviors. (And we actually can, if popular demand takes us in that direction). So take a few moments and think about both the great and the terrible leaders in your experience. Compare their behavior to Dr. Cohen’s checklist. How do they come out? I’ll bet that they are probably doing a good job of exhibiting the eight behaviors of excellent leaders. Now that you’ve thought about it – share your thoughts! Send me your emails with examples of excellent leadership in action or, sometimes even better, share your stories of leadership train crashes!
If you don’t have the opportunity to lays hands on Dr. Cohen’s book, at least look up his web site and read more there. I’d start with his recommendations for 30 Vital Actions for Leaders at http://www.stuffofheroes.com/30_vital_leadership_actions.htm and then explore from there.
And as always, your comments and thoughts are appreciated.
Imagine you’re working on a new project. It’s an important project and its success will be a big win for the organization. You were chosen for the job because of your competency, skill, and effectiveness. You get things like this done all the time and have a track record for pulling it off. Now that the project is underway, you’re finding that trust and support you need from management is absent. Instead, you’ve got a micromanaging boss, who’s put so many additional requirements on your for reporting, meetings, and whatever their favorite nit-picking happens to be that management is actually an impediment to successfully completing the project!
Bad bosses are the suck
The bad news is that this happens to all of us at some time or another. In fact, it’s so common that exit interviews show that nearly one in three professionals have changed jobs to escape micromanaging or unreasonable bosses. The good news is that you can survive and even prosper under this sort of “boss behaving badly” scenario.
The WHY of Micromanaging
The first step towards surviving a micromanager is to understand why they are micromanaging. There are three main reasons that bosses micromanage:
It’s Not the Boss, It’s You: A little people-watching should reveal to you whether the manager acts this way with everyone on the team or whether it’s just you. Yes – it actually is possible that you’re the only one (or a part of small number of people) in a larger team that are getting the “breathing down your neck” treatment from the boss. If this is the case, you’re probably perceived as not meeting the standards of professionalism where you work. I had one colleague complain about being micromanaged by our mutual boss, while never seeming to realize that she left early both for lunch and at the end of the day and seemed to arrive late most mornings and when returning from lunch. On top of that , the quality of her work was mediocre on her best days and was frequently late. Sadly – some people need to be micromanaged or the manager might never get an honest day’s work out of them.
Bad bosses make the team less effective, not more effective
It’s the Boss, and They Know It: This second sort of boss is probably the worst kind that you’ll ever worked for in my professional career (stints at fast-food places as a teenager excluded). This sort of boss revels in being the boss. They don’t really care if you’re good at what you do or if the team is particularly successful (though they don’t want their team to become an abject failure since this puts them in jeopardy with their own boss). Instead, this boss is most interested in the exercise of power and might do things like require undue approval, frequent reports and status meetings, and frequent revisions to the work you’re doing. This sort of micromanaging boss is also prone to publicly disciplining their subordinates. There’s seldom much you can do to make this work environment better and, almost always, the team experiences high turnover – losing most members with 24-36 months.
It’s the Boss, and They DON’T Know It: This final type of boss is one that you can work with. And if they’re otherwise a rational and reasonable person, someone you can probably prosper with. In this case, the micromanaging boss is unconsciously motivated by fear and anxiety. At some point in their past, they failed miserably due to some situation that went out of their control. Now that they’re in charge, they’ll do everything in their power (subconsciously or not) to make sure they never experience that again usually by micromanaging everyone on their team.
If the scenario is about your work behavior, then fix that first. Don’t give a micromanaging boss any excuse to watch you like a hungry hawk by being surfing the Internet, hanging out at the water cooler, or not being timely. If the scenario is about a boss who uses micromanagement as a means of exercising power, simply get out of that team as soon as possible. But what about the third scenario?
Anxiety Manifested as Micromanaging
So what are the tips and tricks needed to get past the boss who micromanages due to a subconscious but exaggerated sense of anxiety? Again, the good news here is that by properly understanding what keeps these bosses up at night, you can answer those needs out of your own initiative thereby giving them good cause to loosen their grip on your every move and show some trust in your talents.
Prioritize: Micromanagers tend to change priorities on the fly because they get caught up in specific, very granular details on a project. They’re notorious for trying to add a multitude of tiny changes that, when taken as a whole, double the amount of effort. However, the granular details are usually unimportant to the success of the project. So it’s your job to keep the micromanager’s eyes on the prize and not focused on the minutia.
Communicate frequently about progress on the project in general (see below).
Send ad hoc emails summarizing any changes in scope and your understanding of the boss’ expectations regarding those changes. Make sure that you also estimate a change in scope to the teams overall ability to meet its objectives. One big change or lots of small changes are equally likely to derail a project or make a team ineffective. Make sure that you explain that sort of impact in your recap email.
It’s even more important to provide recap emails if a scope change comes out of a verbal exchange. Verbal exchanges, after all, don’t have a paper trail if there’s ever a dispute.
Develop a shorthand or code for prioritizing work that makes sense to you both. Any time the micromanager tries to pile on too much work or make too many changes, make sure that they rate such work on a scale of importance. It doesn’t matter what the scale is, 5-stars or 5-alarms for urgent, as long as you both agree. If you have 30 low-priority action items on your list and 1 top-priority item, you both already know which one you should be working on.
Perhaps most importantly, use the micromanager’s nit-pickiness to renegotiate priorities to your advantage. If they ask for such big changes that it impacts the project deadlines or ask for so many small changes that you can’t make any forward progress, don’t say “Yes, I can do that”. Instead, any time they suggest more than a very minor change, tell them “I can do that, but only if one of these other changes drops of the list. Which of these do you want me to put on the backburner?” They’ll feel engaged and see your own level of engagement and dedication to the project as a positive.
As an add-on to reprioritizing, you must put double-emphasis on any action items that you need from them. In a sense, you should micromanage them! By making clear where you need their help to make the project a success, you keep their eyes on the big goal. Plus, by forcing them to refocus on their own responsibilities, you gain a little extra space to get your work done without them constantly looking over your shoulder.
Overcommunicate: Micromanagers, whether they’ll admit it or not, are afraid of not knowing what’s going on. You can conquer the micromanager’s need to be constantly “up in your stuff” by providing them timely updates on your projects and activities.
Provide email updates more often than you might normally like, a couple times per week at least. The emails should not only detail progress on the project, but also provide a steady stream of reassurances that you’re on track regarding timelines and that you’re aware of the importance of the project. This alone will go a long way towards quelling their inner anxieties.
Make sure that they call meetings that accomplish a specific goal: deciding on an important strategy, setting the priority on a bunch of work orders, anything but mere status updates. Status meetings are a huge waste of time. Everyone at the table waits and wastes 50 minutes in a 60 minute meeting, since each person talks in turn and usually try to hard to make themselves look good in the process.
Don’t hide behind email. We have many types of communication available, each with their own degree of intimacy and immediacy. Email is distant. If things aren’t going well or your own stress-levels are going through the roof, sit down with the micromanager for a talk. If you’re not geographically close, ask for a phone call. It’s easy to turn a blind eye to an IM and to procrastinate on an email. But an in-person meeting sets a very different tone.
During this conversation, remind the manager that you’re there to make their projects (and by extension, them) a success and that “administrivia” has reached a level where it’s impeding your ability to engender their success.
You might want to appeal to their sense of propriety – every business relationship is an implicit contract (if not an explicit one). That means both parties have certain responsibilities. The agreement between superior and subordinate is “you do want I ask and I’ll try to make that as easy for you as possible”. You can appeal to the micromanager’s ingrained desire to keep an agreement by gently showing where their side of the agreement has gone off course. Demonstrate how much work you’ve accomplished using your email paper trail as evidence, then use the same evidence to show the degree of unneeded or additional work heaped on you. Refocus the micromanager on the project goals and deadlines, and then point out that there’s simply too much micromanaging, er, work required to meet the deadline. In a sense, you’re steering them to the decision that you want them to make – more trust to get things done, a little less ad hoc reports, fewer boring and unproductive meetings.
Use inclusive pronouns like “we” and “us” to set a collaborative and consensual tone, something like “We’ve got way too much on our plate to get all of this done by the deadline. We don’t want this to be a flop. Which of these can we drop to get us back on track?”
Tenacity: Keep at it. Micromanagers act the way they do literally because of who they are. You can very likely build enough trust with a micromanaging boss to earn a few feet of breathing space and less scrupulous attention detail. But you’ll never fully escape it if you work for a micromanager. You’ll have to build attention to detail and overcommunication into your daily routine. As it says on the shampoo bottle, “lather, rinse, repeat” then get up and do it again tomorrow.
Gimme the Cliff Notes
Micromanagers make us feel untrusted and stymied by their constant need for tediously detailed and frequent updates, constant changes to minor details of our work, and overly developed attention to administrative details that really don’t matter in our daily job. But there’s hope! By proactively micromanaging the micromanager, you can build trust and earn their respect. Overcommunicate on the details of your work. Constantly seek their explicit prioritization for changes to your scope of work. Make sure that any changes are rated for importance and evaluated against the overall goals of the team. And when things get bad enough, schedule a meeting to realign project tasks and to get the project back towards accomplishing your mutual goals within a defined deadline.
