This is my first full year working at my agency, so it’s the
first time I’ll get an annual employee evaluation. Is there anything I should
be doing to get ready for the evaluation meeting with my supervisor? My salary
doesn’t change based on the evaluation, so should I even care about it?
Signed, Lake Wobegon Effect
Your annual evaluation matters, even if it does not affect your pay directly. (Pay-for-performance schemes were a fad in the public sector some years ago, but they have mostly died out.) The annual evaluation is the one time your employer has to make an official statement about how well you do your job. When you apply for a promotion or career development opportunity from your current employer, or apply for a job somewhere else, your record of evaluations will be part of your qualifications. If your employer gives bonuses or awards, even if they are not based on your annual evaluation, the awarding official may be reluctant to stick his neck out by making a judgement that is inconsistent with your most recent evaluation. And if you ever get into a dispute where your employer may take action against you… Read the rest in Federal Times:https://www.federaltimes.com/your-career/the-bureaucrat/2019/05/30/dear-bureaucrat-should-i-worry-about-my-annual-evaluation/
My boss insists on checking over any work I do before it goes to anybody outside our division. When he makes changes, they aren’t really improvements. I don’t think he’s trying to claim credit for my work, because he lets me send it under my name after I put in his changes. But I feel belittled, the needless review creates extra work and delay, and people think I’m late doing my part of projects, when the real problem is it’s waiting for my boss to check. How can I get him to be less controlling?
One approach is to discuss your feelings frankly with your boss. Don’t do it! Because your frank feelings are, “Your unwillingness to delegate to me is a personality flaw, or at least a lack of management skill.” That won’t help, and is probably a misdiagnosis.
Professor Carrie Leana researched the factors that predict whether a supervisor requires an employee’s work to get his approval before it goes out, or delegates to the employee. She found that differences among supervisors, in their need for dominance and their opinions about the proper role of supervisors, did not predict how much they delegated. But a supervisor’s perceptions of any particular employee’s capability, responsibility and trustworthiness was a relatively strong predictor of how much he would delegate to that employee. Interestingly, there was no significant relationship between a supervisor’s perceptions of a particular employee and objective measures of the employee’s job performance.
I feel like I’m missing out. People are starting companies and nonprofits, and I’m just holding down a job. If I stick with it, I’ll get promoted eventually, but I’ll still be a cog in a dreary machine. I want to be an entrepreneur and build something I’m proud of, but I’m afraid to give up my steady paycheck. Should I take the leap, quit my job, and work full time on finding a dream to make real? Or should I wait until I develop a can’t-fail idea and then take the plunge?
Signed, Mark “Hoodie” Z.
You’ve been influenced by two kinds of romanticized startup stories. The first is total commitment; working sixteen-hour days so you can code all night and pitch all day, living in a group house and subsisting on instant ramen, until you attract venture capital and then make it big. If it doesn’t work out, then you start picking up the pieces of your life. The second story is getting a brilliant idea and developing a business plan that maps step by step how to implement it, so the risk of failure isn’t even part of the story.
Jonathan Shepard replies to Dear Bureaucrat’s column on a useless computer system:
While you’ve identified some useful workarounds here, I do believe that the root cause of this problem (across the government) is a fundamental mismatch between the strictures of the federal procurement process and the software development (and support!) lifecycle. As you know, when federal agencies need to procure an IT product or service, they have no choice but to go through their agency’s procurement systems, often with a set of half-baked requirements. Nothing inherently wrong with half-baked requirements; many requirements (even in the most innovative companies) are only partly articulated until they get deeper into product development. That’s why there is such a thing as agile software development. But the problem is that the federal contracting process is fundamentally ill-equipped to support agile software development. And as the example you cited demonstrates, there is little consideration in most federal contracts for ongoing support and evolving needs. Federal IT systems are generally regarded as one-time “projects” in a project management sense. They are not. They are products with sophisticated users, evolving needs, and changing requirements. A FOIA request management system is a product in the same way that Uber (or Gmail) is a product. Federal IT systems are inexcusably terrible. I am a former PMF, currently working in the tech sector. The “technological” challenges facing federal agencies are (for the most part) very solvable, sometimes laughably so. If tech startups were able to compete in a truly free market for federal agencies’ business, judged solely on the quality of their products and customer satisfaction, it could revolutionize federal IT systems and bring them up to par with the private sector, probably at a fraction of the cost currently being expended by federal agencies. But there simply isn’t a way to do it today, with existing procurement processes. Great developers don’t bid on RFPs. Great developers make great products, and let them speak for themselves.
My agency uses an on-line system for responding to Freedom of Information Act requests, but the system is useless. Half the people who need to work on a request don’t have passwords for the system, so I need to constantly email and phone them about what they need to do. There are review and approval steps that my agency requires, but aren’t part of the workflow in the system, so I have to remember who needs to see what, whether they’ve responded, etc. Every step I have to do that the system pretends doesn’t exist is another chance for errors to creep in, which I get blamed for. I’ve talked to IT about matching the system to what we actually need to do, but they say the development contract ended years ago, so there’s no budget for changes. What can I do?
Signed, Charlie “Modern Times” C.
Occasionally an agency is forced to admit that a system development project failed. But your problem in more common—the system is bought, paid for, and officially a successful implementation. It just doesn’t do what the workers need to get their jobs done.
The fix is that workers create our own solutions to do what the official system doesn’t. Spreadsheets are the most common form, but people also use templates, macros, web-based file sharing services, etc. IT departments call this “shadow IT” and point to the security risks. I prefer the term “cuff system” which goes back to when bookkeepers would write a number on their shirt cuff to remember a figure that wasn’t in the official ledger. As to security, the data breaches that have made headlines were from official enterprise systems. Cuff systems done properly can beat that record.
Do you work in the public sector — government, contractors, and grantees? Do you want advice? Send your question to DearBureaucrat@PubAdmin.org Or use our on-line form. Anonymous questions are fine, and we won’t print your name even it you give it.