People change employment and/or lose employment every day. Most people know the basics:
1) Try to give two weeks notice
2) Try not to burn any bridges on the way out
3) Take all your stuff on the last day
4) Leave all their stuff (badges, etc.)
Let's go over what I actually mean by those basics.
1) Try to give two weeks notice. There are always going to be times when you cannot give two weeks of notice; you have a vacation planned or the new job is "get in here ASAP or don't get in at all" are reasons that commonly come up.
However, no matter how upset you are with the company you are leaving or excited to be going to the new job to which you are going, you usually give two weeks of notice to prove that a) you honor your commitments and b) give the company you are leaving time enough to sort out what happens because you are leaving.
Honoring your commitments is important to note, not just to maintain good relations with the job you are leaving (and subsequent references), but for the job to which you are going--sure, they want you as soon as they can get you oftentimes, but some part of them will keep track of what you're willing to do to your current employer in order to get into your next employer's good graces and will, eventually, do the math that they could end up as the current employer being screwed at some point in the future. That's not a good thought with which to start a new working relationship.
You may believe, by the way, that you will never do this again--the company you're leaving is toxic and horrible and deserves a short amount of time before you get out while the new company is noble and awesome. However, the old company started with some kind of awesome before, or you wouldn't have worked there at all. So no matter how toxic it feels, stick it out for suggested two weeks. You have, after all, only known the new company for five hours of interview time (or less) plus some email and random web searches; how much do you really know about how awesome they really are, other than they are not the current toxic place? They might not be worth shortening that expected time frame and causing friction with a potential employment reference in the future.
2) Try not to burn any bridges on the way out is one of the hardest things to do for some folks; its not that they are bad people, its just that the situation has become so problematic and been left for so long that its hard to stay amicable during the last days of employment.
You'll be tempted to tell your boss what you really think about (insert the blank). Or worse, send an email or a memo about things. It's common sense, but let me state for the record here: don't.
Almost all future employment forms ask for your boss's name. In most states, legally, your boss cannot say anything negative about you in those phone calls with a company calling to verify your employment--if the company verifying your employment (or anyone else) responded with negative things that were said about you to you, you could sue your boss and the company for defamation and/or slander. Since no one wants to be sued, typically the whole employment checking/reference checking thing is done very carefully. However, you aren't on that phone call and neither is your lawyer. The standard question most commonly asked when checking in with this type of reference (to avoid legal issues) is "Would you hire this person again?" and if your boss says "No," even if he cannot legally explain it and therefore, does not explain it, he has just kabashed your future prospects. In other instances, he or she could use tone of voice to convey their true thoughts about you telling them how much you hate that purple tie they wear every Thursday.
So, try not to piss off your boss any more than you already have by finding another job.
Next, DON'T PUT ANYTHING IN WRITING. Let's say that again: don't put any of your displeasure, unhappiness, feelings about work or whatever, in writing. Writing lives forever in an HR file. Companies can quote it when they're providing a reference, because its words you said, yourself--no risk of slander or defamation. Rant to your friends, write letters at home you tear up, but resist the urge to write things down that are wrong about the current environment and send them to your boss, HR, or any directly responsible parties.
But what, you may ask, about your exit interview? First of all, not all companies provide exit interviews, or, they are handled by your current, direct boss. In the case where something is so bad its possibly illegal or may cause other employees to quit the company, you may wish to request an exit interview with a person in Human Resources so you can communicate what's going on. But you rarely want to tell your boss directly unless you have an iron clad, tight relationship with him or her, and even then its best to wait and talk to HR.
Provided you have an exit interview, spend some time BEFORE the interview figuring out what you are going to say. To avoid burning bridges, you will remove all emotional language and treat it as just the facts: for example, "Kevin, my boss, is a super human being but cannot make his own meetings on time, usually on the scale of 1.5-2 full hours late, during which time the team is unproductive while we wait for him, because not waiting for him causes him to get upset with us and reflects on our regular reviews" rather than "Kevin, my boss, is always late. ALWAYS. He treats us like our time means nothing to him and we're here to just wait around for him. Once he rolls in, two hours late, and we're not there because we're actually getting work done, he threatens to write us up in our reviews for not making his meetings."
While I kissed up a bit in the first example--calling Kevin a "super human being"--I otherwise stated the facts of the case. In the second example, I complain about what Kevin has been doing as I try to explain what he's been doing; that erodes my credibility over the actual facts and paints me as a complainer/whiner rather than Kevin as a bad boss. Negative emotion injected into an exit interview recitation of issues and events affect your credibility and not the credibility of the person who you are responding to negatively. So keep it neutral, polite, to the point, just the facts, and be able to provide examples.
Prior to the exit interview, there's that two week window you have to work while everyone knows that you are leaving. I think of it as "Dead Man/Woman Walking" time. Basically, people avert their gaze, stop talking when you walk up, and/our plaster fake smiles on their faces while they ask pleasant, but expected questions about your next opportunity. It can get a little tiring, and as tempted as you might be to write out all the answers to the questions you keep getting asked and then hand the card to the next lucky questioner, control yourself. Be nice to everyone. Smile, even if they avert their eyes. Any one of these people could go to work at another place and pass on your resume if they think you're a decent person, should you ever need that sort of help in the future. Any one of these people could field the reference call about your work experience here. Best to keep it light, sociable, slightly regretful, but most of all, professional.
Finally, there's battling the clock. First, a lack of interest can be the problem: sometimes called "Short timer's Syndrome," there's this lack of urgency about things because in X number of days you'll never have to worry about that problem again. It might make you fail to deliver on your final deliverables, or otherwise be construed as a person not taking the job seriously. This is not the performance you want people at the job remembering about you (because, remember, you won't be here next week to remind them you're cool and get stuff done).
Second, there's an over interest in trying to get everything finished before you're gone and you cannot get it done anymore. This slavish loyalty to completing a project, helping your friends at this job, or just being loyal to the company can lead to you taking on too much work and not being able to complete it, causing people to remember poor performance on your part as you leave.
The trick is to walk the line closer to "less work" but still in the "getting work done" realm. Promise completion of projects that you know you can complete in less time than what is left, and then get any additional items you can get done, done, in the time after. So, for example, if I know that finishing the documentation on how to do all the items I know how to do will take a week, tops, I'll probably tell them it will take two weeks; when I finish, I'll take on additional small assignments until I go so that they feel like I really worked hard for them at the end--look at all the stuff she got done right before the end...rather than setting impossible expectations and having them be disappointed with your performance.
3) Take all your stuff on/by the last day. I should add, "and tidy your work area." No one wants to empty your filing cabinet of all the soy sauce packets you've collected in the last three years because you (rightly) realized you didn't need to take them with you. Plan out your move if you have a lot of stuff in your cube/office/on your desk, and make sure that the last load is gone on the last day. Don't try to arrange to come back later for more of it--it's just awkward and leaves things with the company and/or your manager feeling awkward; again, not the last emotion that you want to leave with them about how they feel about you prior to picking up the phone and responding to another company checking a reference.
4) Leave all their stuff (badges, etc.). Talk to your boss shortly after you announce leaving and set up a process by which to get work stuff into work. For example, the last day/time you will check in code to the repository, where you will drop off your badge, where you turn in your keys, etc. It's small stuff, but it leads to a lot of security issues if its not worked out, which may leave you liable for any security violations that happen after you leave (especially if you didn't do them, but your stuff--such as your badge--was used). Don't want to be sued for stealing company secrets your racing to get away from, so set this stuff up soon and follow the plan with your boss.
The four things seem pretty basic, but most people don't have a complete understanding of all the things going on under the hood. I'm not entirely sure I know everything about it--enough to be dangerous and share with you, I suppose.
Look out for the next article in this series, Part 2: You don't Initiate Leaving, But You're Leaving Anyway.
Tuesday, October 4, 2011
Tuesday, September 27, 2011
Breathing Underwater
As noted in my previous blogs regarding screw ups in the workplace, sometimes what we do can make it harder to do our jobs. Sometimes, however, we are dumped into the deep end of the pool and have to keep everyone's head above the water, including our own, in a situation that we did not make for ourselves.
The first thing to do is to determine if you are actually underwater. By being underwater, I mean that your tasks and their scheduled complete date are sufficiently in jeopardy that if you had to choose between green status (all good), yellow status (likely ok, but problems) and red status (dear god), you'd put yourself in red status.
An example from my own life involved taking on a project for my company with a bank. The project had been scoped and approved and then paid for by the IS department of a specific group...then, during the time before the planning phase started, the company reorganized and a different group ended up with the contract. These folks did not want an external development company; their leader wanted full control over the project. He did what he could to get me and my team to literally move to Boston where he could supervise us. That was not in the contract, so we had several meetings, put together a plan and a schedule, and started moving forward.
Unbeknownst to my company and myself, he began hiring contractors. He already had one, but added two more. He gave them direct orders, often counter to what he agreed on in meetings with me and what they agreed upon in meetings with the entire team. Meetings we had DAILY to prevent this type of cross communication.
Once I caught on that, effectively, the other team had gone rogue at the customers request, I spoke with my boss and then the company president. Looking at my daily numbers, we were not only not moving forward on the schedule, in many cases we were moving backwards as my team had to fix things that had gotten broken, or throw away code that would no longer be used due to a change in direction that happened in a time zone three hours ahead of ours.
Armed with my daily numbers regarding checkins, bug fixes, feature progress, emails from all developers involved, I approached my boss and his boss and made the recommendation to simply end the project. If the project was being, effectively, sabatoged daily, then we needed to get out with our reputation intact and no additional monetary losses.
For reasons that made sense only to upper management, my request was not approved. I had to schedule more regular meetings with the client, meetings where the president of the company was present. Meetings were I got dressed down, nearly every day, for things that had been discussed the previous day. But I persevered. I've talked about the value of documentation before, and this is the project that brought that home for me. For every allegation, I had a document on why it had been done and who had approved it.
Eventually we achieved a rhythm; my team would come in and spend the first hour or two of the day undoing checkins from the Boston team. Then they'd fix the code the Boston team had made plug it back in, make sure the build wasn't breaking and the tests were now running, and then they'd start their work. Where you normally assume a person isn't productive eight straight hours a day, and I typically assumed six hours of productive time, I modified my schedule to include this maintenance and dropped them down to three hours of productive time per day and stopped counting the Boston team's work at all.
Suddenly, the client was getting what he/she wanted (in a really convoluted, frustrating way). I was able to alter the schedule and scope. I brought in Starbucks cards and toys and books for my team--every time they had to undo a tangle created by the Boston team, they got a prize.
In return, on the day when they finally got the build automation and test automation to work perfectly--greens all across the board--they took a picture of themselves doing the "Vanna White" thing with the monitor holding the good news and sent it to me (I was home sick that day). The whole team, grinning ear to ear made it clear I'd gotten their heads above water, and that, maybe, I had developed some gills. We did end up delivering on time and on budget, with the new schedule and scope.
Not all projects are that bad. But I think of that whenever a project I'm working on looks dire. At least, I think, its not that project all over again.
So basically, the steps to managing an underwater project break down as:
1) Realize you are underwater. Accept. Do not panic
2) TELL SOMEONE. Specifically your boss and/or his boss. The sooner people know, the sooner they can help, but also the sooner they can adjust their expectations.
3) It's ok to recommend that you close or cancel a project that is under water. You can do this based on return on investment (the calculation that the project is costing the company more than they'd get for completing it). But only do this if that is absolutely the case, and you have clear measurements to prove it.
4) You might get help, you might not. At the end of the day, the project underwater is your project. You will have to use what you have available to get back to the surface (and hopefully beyond)
5) Things you have to help you: the ability to adjust schedule, the ability to adjust scope, the ability to adjust resources. As we discussed in the Iron Triangle post, these are three things that make up a project; adjusting any one of them affects the others. So to pull yourself out of being underwater schedule-wise, you can add resources and reduce scope. To meet an expanded scope, you can extend schedule and resources, and to deal with fewer resources you can extend schedule and reduce scope. In my example above, that's what I did: I assumed fewer resources (because my team was undoing the work of the other team) and shrank scope and expanded schedule accordingly.
6) Address morale. Even if you don't actively have a team working against your team, being on an underwater project reduces morale. Death marches are often a technique used to try and get back out from under water, and, for a short time, they work, but the damage to morale affects the long term effectiveness and usefulness of your resources. You need to keep morale up, even if it means breaking for lunch together despite the fact there's still work to do.
7) Be creative. These prescriptive steps don't cover it all; the fact my team was thinking of beating the hell out of one of the developers when he came over to learn more about our systems required me to make each time they had to undo someone else's mistake a rewarding experience, to reduce the overall frustration. AS a manager, donuts, coffee, toys and books are a small price to pay to avoid homicide and to get a project done. But whatever works for me might not work for you--so be creative.
8) Keep communicating. Daily if you have to. No one wants to be surprised when a project goes underwater and stays there and maybe fails to meet dates or scope requirements. Keep everyone in the loop on the blocking issues and what you're doing to resolve them. Not every project will work out. You will have failures. This documentation will protect you and provide information for a project post mortem (a common technique where people call a meeting to find out what happened during the project). Often post mortems for projects that did not succeed become blame games that are not useful. But the communication, summaries and reports you keep during the process can clearly identify what was what, and keep the unproductive blame game at bay.
The first thing to do is to determine if you are actually underwater. By being underwater, I mean that your tasks and their scheduled complete date are sufficiently in jeopardy that if you had to choose between green status (all good), yellow status (likely ok, but problems) and red status (dear god), you'd put yourself in red status.
An example from my own life involved taking on a project for my company with a bank. The project had been scoped and approved and then paid for by the IS department of a specific group...then, during the time before the planning phase started, the company reorganized and a different group ended up with the contract. These folks did not want an external development company; their leader wanted full control over the project. He did what he could to get me and my team to literally move to Boston where he could supervise us. That was not in the contract, so we had several meetings, put together a plan and a schedule, and started moving forward.
Unbeknownst to my company and myself, he began hiring contractors. He already had one, but added two more. He gave them direct orders, often counter to what he agreed on in meetings with me and what they agreed upon in meetings with the entire team. Meetings we had DAILY to prevent this type of cross communication.
Once I caught on that, effectively, the other team had gone rogue at the customers request, I spoke with my boss and then the company president. Looking at my daily numbers, we were not only not moving forward on the schedule, in many cases we were moving backwards as my team had to fix things that had gotten broken, or throw away code that would no longer be used due to a change in direction that happened in a time zone three hours ahead of ours.
Armed with my daily numbers regarding checkins, bug fixes, feature progress, emails from all developers involved, I approached my boss and his boss and made the recommendation to simply end the project. If the project was being, effectively, sabatoged daily, then we needed to get out with our reputation intact and no additional monetary losses.
For reasons that made sense only to upper management, my request was not approved. I had to schedule more regular meetings with the client, meetings where the president of the company was present. Meetings were I got dressed down, nearly every day, for things that had been discussed the previous day. But I persevered. I've talked about the value of documentation before, and this is the project that brought that home for me. For every allegation, I had a document on why it had been done and who had approved it.
Eventually we achieved a rhythm; my team would come in and spend the first hour or two of the day undoing checkins from the Boston team. Then they'd fix the code the Boston team had made plug it back in, make sure the build wasn't breaking and the tests were now running, and then they'd start their work. Where you normally assume a person isn't productive eight straight hours a day, and I typically assumed six hours of productive time, I modified my schedule to include this maintenance and dropped them down to three hours of productive time per day and stopped counting the Boston team's work at all.
Suddenly, the client was getting what he/she wanted (in a really convoluted, frustrating way). I was able to alter the schedule and scope. I brought in Starbucks cards and toys and books for my team--every time they had to undo a tangle created by the Boston team, they got a prize.
In return, on the day when they finally got the build automation and test automation to work perfectly--greens all across the board--they took a picture of themselves doing the "Vanna White" thing with the monitor holding the good news and sent it to me (I was home sick that day). The whole team, grinning ear to ear made it clear I'd gotten their heads above water, and that, maybe, I had developed some gills. We did end up delivering on time and on budget, with the new schedule and scope.
Not all projects are that bad. But I think of that whenever a project I'm working on looks dire. At least, I think, its not that project all over again.
So basically, the steps to managing an underwater project break down as:
1) Realize you are underwater. Accept. Do not panic
2) TELL SOMEONE. Specifically your boss and/or his boss. The sooner people know, the sooner they can help, but also the sooner they can adjust their expectations.
3) It's ok to recommend that you close or cancel a project that is under water. You can do this based on return on investment (the calculation that the project is costing the company more than they'd get for completing it). But only do this if that is absolutely the case, and you have clear measurements to prove it.
4) You might get help, you might not. At the end of the day, the project underwater is your project. You will have to use what you have available to get back to the surface (and hopefully beyond)
5) Things you have to help you: the ability to adjust schedule, the ability to adjust scope, the ability to adjust resources. As we discussed in the Iron Triangle post, these are three things that make up a project; adjusting any one of them affects the others. So to pull yourself out of being underwater schedule-wise, you can add resources and reduce scope. To meet an expanded scope, you can extend schedule and resources, and to deal with fewer resources you can extend schedule and reduce scope. In my example above, that's what I did: I assumed fewer resources (because my team was undoing the work of the other team) and shrank scope and expanded schedule accordingly.
6) Address morale. Even if you don't actively have a team working against your team, being on an underwater project reduces morale. Death marches are often a technique used to try and get back out from under water, and, for a short time, they work, but the damage to morale affects the long term effectiveness and usefulness of your resources. You need to keep morale up, even if it means breaking for lunch together despite the fact there's still work to do.
7) Be creative. These prescriptive steps don't cover it all; the fact my team was thinking of beating the hell out of one of the developers when he came over to learn more about our systems required me to make each time they had to undo someone else's mistake a rewarding experience, to reduce the overall frustration. AS a manager, donuts, coffee, toys and books are a small price to pay to avoid homicide and to get a project done. But whatever works for me might not work for you--so be creative.
8) Keep communicating. Daily if you have to. No one wants to be surprised when a project goes underwater and stays there and maybe fails to meet dates or scope requirements. Keep everyone in the loop on the blocking issues and what you're doing to resolve them. Not every project will work out. You will have failures. This documentation will protect you and provide information for a project post mortem (a common technique where people call a meeting to find out what happened during the project). Often post mortems for projects that did not succeed become blame games that are not useful. But the communication, summaries and reports you keep during the process can clearly identify what was what, and keep the unproductive blame game at bay.
Wednesday, September 21, 2011
How (Some) Kindergarten Rules Apply in the Office
No hitting
Inside voice
Share (No stealing)
Understand who Authority Is
Challenge Authority
Inside voice
Share (No stealing)
Understand who Authority Is
Challenge Authority
Tuesday, September 20, 2011
The $10,000 Pen
When I was working for a start up in Silicon Valley, we went under. It was called the dot com bomb, or dot com crash. A brief side note--it's not a selling point that you're CEO has been hit by lightening twice, as ours had been. Once is understandable, but twice is basically either stupidity or egging on the fates (or both). Whichever it was, it totally caught up to us.
Miraculously, 13 of us from the company that closed its doors were purchased with our technology and brought to work for a wharehousing company that wanted to be able to provide e-commerce sites to their customers.
When hired, we were promised our original rate of pay. Some got bonuses. I got a typo. A very nice typo--I was make A LOT more money than I had been making, and I didn't correct them.
Three months later came the first pay cut. Everyone grumbled--it was 10%; I did ok, as I had the typo. I was making less, but still more than I had originally been making.
At six months, the managers took another pay reduction.
On our one year anniversary, we were all gathered into a room for a party--we celebrated and laughed and talked about how miraculous that we had made it after the previous .Com fell. Then we were thanked for our service.
Then they announced another 10% pay cut.
Finally, they handed us all a pen as a present for our one year of service. I carried it reverently--even with my typo, that pay took me $10K less than I had been making at the previous company. I thought about taking it out back and running over it, since running over the new management was not an available option.
Basically, the point of the story is that what you do and how you do it set the tone for how people feel about you and the company.
Take the first paycut: a solid, sympathetic meeting explaining that certain contracts had not come through (or any convenient lie) and a reach out by the HR team to talk about our feelings and make us at least settled with our cut would have made us feel like part of the team, doing our part (although reluctantly) in keeping the company that kept us afloat, afloat.
I was a lead, and not a manager. I imagine the manager cuts sucked, but they didn't say much about them, so I cannot speak to how they could have been done better.
I can imagine the last round of paycuts could heartily have been managed better. Step 1) Meeting about pay cuts. Address concerns, fears, and thankfulness the company decided to reduce pay rather than lay anyone off. 2) Separate party thanking us for stayinng with them for the last year, despite the difficult times, and being told we were appreciated. Finally, acknowledging a pen is not equal to a paycut, but that they wanted to show us, in some way, that they appreciate us, even if they could not do it with the monetary recompense they would like.
Tada! It still sucks, but then everyone's still on the same side.
The way they handled it, however, made it very "us" v. "company." Our lead dev started doing 80% of his work, because that was what he was being paid. We lost two people almost immediately after their talks with management were not "Here's what is happening and why we had to lower your pay" but "No, there's no possibility of an increase, you should be happy you have a job."
The morale of the $10K pen story is that how you present things to people may not be the way they see them. When you are delivering news--especially ambiguous or bad news--you need to be honest with people AND appreciative of the work their doing in praise and words...not just a cheap pen.
As the manager, you typically have little control over random finance changes, like across the board paycuts. But much like a third grader may not be able to control a bully telling her she's ugly, she (and you) can control how she reacts to the unpleasantness and form a reaction of her own making. It is important to the third grader for her eventual maturity, and it's important to you as a manager if you want your team to continue to be happy, let alone stick around and work together.
Sometimes you can't stop the company from making itself the "bad guy" through policies and actions. But you, yourself, can be allied with the employees, per their perceptions, and make a much better work environment out of something, no matter how lousy it may get.
Miraculously, 13 of us from the company that closed its doors were purchased with our technology and brought to work for a wharehousing company that wanted to be able to provide e-commerce sites to their customers.
When hired, we were promised our original rate of pay. Some got bonuses. I got a typo. A very nice typo--I was make A LOT more money than I had been making, and I didn't correct them.
Three months later came the first pay cut. Everyone grumbled--it was 10%; I did ok, as I had the typo. I was making less, but still more than I had originally been making.
At six months, the managers took another pay reduction.
On our one year anniversary, we were all gathered into a room for a party--we celebrated and laughed and talked about how miraculous that we had made it after the previous .Com fell. Then we were thanked for our service.
Then they announced another 10% pay cut.
Finally, they handed us all a pen as a present for our one year of service. I carried it reverently--even with my typo, that pay took me $10K less than I had been making at the previous company. I thought about taking it out back and running over it, since running over the new management was not an available option.
Basically, the point of the story is that what you do and how you do it set the tone for how people feel about you and the company.
Take the first paycut: a solid, sympathetic meeting explaining that certain contracts had not come through (or any convenient lie) and a reach out by the HR team to talk about our feelings and make us at least settled with our cut would have made us feel like part of the team, doing our part (although reluctantly) in keeping the company that kept us afloat, afloat.
I was a lead, and not a manager. I imagine the manager cuts sucked, but they didn't say much about them, so I cannot speak to how they could have been done better.
I can imagine the last round of paycuts could heartily have been managed better. Step 1) Meeting about pay cuts. Address concerns, fears, and thankfulness the company decided to reduce pay rather than lay anyone off. 2) Separate party thanking us for stayinng with them for the last year, despite the difficult times, and being told we were appreciated. Finally, acknowledging a pen is not equal to a paycut, but that they wanted to show us, in some way, that they appreciate us, even if they could not do it with the monetary recompense they would like.
Tada! It still sucks, but then everyone's still on the same side.
The way they handled it, however, made it very "us" v. "company." Our lead dev started doing 80% of his work, because that was what he was being paid. We lost two people almost immediately after their talks with management were not "Here's what is happening and why we had to lower your pay" but "No, there's no possibility of an increase, you should be happy you have a job."
The morale of the $10K pen story is that how you present things to people may not be the way they see them. When you are delivering news--especially ambiguous or bad news--you need to be honest with people AND appreciative of the work their doing in praise and words...not just a cheap pen.
As the manager, you typically have little control over random finance changes, like across the board paycuts. But much like a third grader may not be able to control a bully telling her she's ugly, she (and you) can control how she reacts to the unpleasantness and form a reaction of her own making. It is important to the third grader for her eventual maturity, and it's important to you as a manager if you want your team to continue to be happy, let alone stick around and work together.
Sometimes you can't stop the company from making itself the "bad guy" through policies and actions. But you, yourself, can be allied with the employees, per their perceptions, and make a much better work environment out of something, no matter how lousy it may get.
Reading Contracts and Editing Them
Non competes
Who owns what work
Moonlighting
This is not legal advice
Tuesday, September 13, 2011
Be an Information Nexus
Dictionary.com defines a Nexus as:
1. a means of connection; tie; link.
2. a connected series or group.
3. the core or center, as of a matter or situation.
4. something to do with cell biology that doesn't match/isn't as applicable as the other definitions, so is being left out. Look, a monkey!
Basically, in the workplace, you don't want to know everything, you want to be the person who knows who knows everything. Other than being really hard to parse, that sentence incorporates the definitions 1-3 above by making you the center, a means of connection and part of being a connected group.
No one who is rational ever expects that you will know everything. But, for example, in interviews people will want to know what you will do when you run across something that you don't know what to do with. The proper answer is "find out what to do with that thing" and then provide examples of how you'd do that.
That seems very common sensical, but, as you know, common sense isn't (to continue with my theme of hard to parse sentences). Most employers would like a base amount of information in your brain when you start, just like your current employer wants you to know enough about your job to do it, but they also want to know that you are prepared to help yourself if you run into trouble.
What works for me, and makes me more valuable to the people that I work for, is that I retain the answer and who provided it each time I have to find an answer to a question; I keep it in email, in my brain, I make notes in my notebook...at one job, I actually kept a database of answers and who knew them. The gist is, you want to become informed beyond just being able to do your own work, but to be productive and useful to other members of your team and to be the go-to person for folks outside of your team, as well. Even if you don't know all the answers, most people don't differentiate between you being all knowing and you being the person who knows the people who know. It reflects well on you and your team, makes you a better candidate for job retention, and can be called upon for a yearly review with concrete examples to prove your value to the company.
As a manager, it makes you seem wise and mysterious. Ok, mostly just wise. Upon occasion your people will still come to you with questions where you cannot easily, on your own, go and find out the answer and those occasions can be opportunities instead of challenges, by mentoring the employee who wanted to know in the way of finding out...and then having the employee report back to you when they have the answer. You'll both be happy--he or she will have the answer they want and you'll have another fact in your arsenal for the next time someone needs to know something.
1. a means of connection; tie; link.
2. a connected series or group.
3. the core or center, as of a matter or situation.
4. something to do with cell biology that doesn't match/isn't as applicable as the other definitions, so is being left out. Look, a monkey!
Basically, in the workplace, you don't want to know everything, you want to be the person who knows who knows everything. Other than being really hard to parse, that sentence incorporates the definitions 1-3 above by making you the center, a means of connection and part of being a connected group.
No one who is rational ever expects that you will know everything. But, for example, in interviews people will want to know what you will do when you run across something that you don't know what to do with. The proper answer is "find out what to do with that thing" and then provide examples of how you'd do that.
That seems very common sensical, but, as you know, common sense isn't (to continue with my theme of hard to parse sentences). Most employers would like a base amount of information in your brain when you start, just like your current employer wants you to know enough about your job to do it, but they also want to know that you are prepared to help yourself if you run into trouble.
What works for me, and makes me more valuable to the people that I work for, is that I retain the answer and who provided it each time I have to find an answer to a question; I keep it in email, in my brain, I make notes in my notebook...at one job, I actually kept a database of answers and who knew them. The gist is, you want to become informed beyond just being able to do your own work, but to be productive and useful to other members of your team and to be the go-to person for folks outside of your team, as well. Even if you don't know all the answers, most people don't differentiate between you being all knowing and you being the person who knows the people who know. It reflects well on you and your team, makes you a better candidate for job retention, and can be called upon for a yearly review with concrete examples to prove your value to the company.
As a manager, it makes you seem wise and mysterious. Ok, mostly just wise. Upon occasion your people will still come to you with questions where you cannot easily, on your own, go and find out the answer and those occasions can be opportunities instead of challenges, by mentoring the employee who wanted to know in the way of finding out...and then having the employee report back to you when they have the answer. You'll both be happy--he or she will have the answer they want and you'll have another fact in your arsenal for the next time someone needs to know something.
Subscribe to:
Posts (Atom)