A recent short piece in NetworkWorld cited a study performed by staffing firm Manpower Group notes that engineers and IT staff are among the hardest positions to fill.
This has certainly been out experience at ICPSR over the past six to eight months. We posted a position in November and another in December and have yet to fill them. Both are more senior positions, one a software developer and the other a systems architect.
My experience is that technology positions at ICPSR are some of the hardest to fill. When ICPSR hires data managers at the entry level, there are usually many good candidates in the pool, including former temps and interns. And when we fill more senior positions in those ranks, it is usually from within (e.g., a promotion from a mid-level data manager to senior-level, or into a supervisory or management positions). But when the technology shop needs to fill a position, it is nearly impossible to hire from within. ("Do you know Java? Or how to manage a firewall?" "No, but I have a background in Political Science and know how to use SAS.")
It could be worse, though. Creating and filling director-level positions in our archives is probably the most difficult job. In this case we're looking for someone who can manage a small team of professionals, manage a relationship with a government agency, and manage a portfolio of grants and contracts. The ideal candidate is also successful in academia, but not so successful that they have no interest in pausing (or greatly shrinking) their research endeavors. And it would also be great if they worked at ICPSR only part-time, keeping an appointment at some other university. And be willing to be in the office in Ann Arbor a few days a week. And....
Showing posts with label human resources. Show all posts
Showing posts with label human resources. Show all posts
Monday, June 4, 2012
Wednesday, May 16, 2012
Job posting: Cloud Sourcing Manager (UMich)
The University of Michigan has posted a cloud-oriented position. This is good news. (The entire position is included in-line at the end of this post; the U-M job system does not retain job descriptions once the posting date has expired.) However, based on my reading of the job description, it has a couple of serious flaws.
One, this position is funded for a single year. Why? Is this because the cloud is a passing fad? Or because this position will be able to achieve complete success in a single year? Why wouldn't this position be funded indefinitely?
[ Edit - I chatted with the hiring manager - Bill Wrobleski @ ITS - and he confirmed that the job actually has funding for at least two years. This is very, very good news, and shows a much bigger commitment. I would also highly recommend Bill as a colleague. ]
Two, the job position itself sends mixed messages. For example, from the Job Summary:
[ Edit - I chatted with the hiring manager - Bill Wrobleski @ ITS - and he confirmed that the job actually has funding for at least two years. This is very, very good news, and shows a much bigger commitment. I would also highly recommend Bill as a colleague. ]
Two, the job position itself sends mixed messages. For example, from the Job Summary:
This solution oriented, flexible and proactive manager will be responsible for working with key process stakeholders such as Procurement Services, Office of General Counsel and IT governance groups to establish effective, secure and sustainable cloud sourcing processes for IT-related activities.
OK, so this is going to be a pretty slow-moving effort, working with some of the most careful, cautious organizations. Work will be in baby steps. Right? However, look at the Responsibilities:
Accelerate the adoption of cloud solutions by removing barriers, streamlining processes and supporting the move to cloud solutions.
Creative problem solving and strong strategic thinking skills.So work with lots of stakeholders AND accelerate the adoption of cloud solutions? How? (And this second thing looks more like a Required Qualification than a Responsibility.)
So in the spirit of offering constructive criticism, here is my unsolicited, unofficial, revised Job Summary:
Information and Technology Service (ITS) is seeking an experienced Cloud Sourcing Manager to promote a "cloud first" culture at the University of Michigan. This person will be responsible for making it easier to purchase and use enterprise-class cloud services (e.g., Amazon Web Services, Salesforce.com) by collaborating with U-M Procurement Services, Office of General Counsel and IT governance groups. This person will also be responsible for lowering barriers to using consumer-class cloud services (e.g., Dropbox, Lastpass) by conducting regular demonstrations and informational sessions (town halls, brown bags) to bring awareness of cloud resources to the entire U-M community.
NOTE: this position is funded indefinitely.So now the person has the opportunity to accelerate cloud use (where it makes sense) while s/he works through the bureaucracy of the U-M to make bigger, systemic changes. I like this more already!
And now for my unsolicited, unofficial, revised Responsibilities. First, I should note that I like all of these ones from the original posting:
- Maintain a broad understanding of cloud marketplace including Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) offerings.
- Manage relationships with cloud vendors including establishing service level standards and reporting.
- Participate on and/or lead project teams that are leveraging new cloud-based products.
- With appropriate stakeholders, support contract negotiation with cloud providers.
- Track the use of cloud services and identify trends and investment opportunities.
- Work cooperatively with higher education consortiums [sic] to provide and leverage expertise and combined purchasing power.
And here are the items I would add. Mine are really specific:
- Negotiate an invoicing mechanism with Amazon Web Services (AWS) such that the U-M receives preferential rates based on aggregate campus usage, not individual department usage
- Using AWS Direct Connect establish a private, secure, low-cost network connection between the U-M campus and the AWS cloud
- Using AWS Virtual Private Cloud establish a private, secure, virtual data center in the AWS cloud for use by researchers and IT staff at the U-M
- Organize a campus-wide "Cloud Day" event at U-M similar to events focused on IT security and cyberinfrastructure, where speakers would present information about real-life use-cases using cloud capabilities to solve real problems
- At least once per month conduct an informational session for some department, institute or similar organization on campus, demonstrating a consumer-grade cloud product, noting its pros and cons, and how researchers and staff may use it safely
I should note that the AWS-related items would also help me out a lot.
And as promised, the original posting:
Cloud Sourcing Manager
How to Apply
A cover letter and resume are required; the cover letter must be PAGE 1 of your resume. The letter should:
(1) specifically outline the reasons for your interest in the position;
(2) outline your particular skills and experience that directly relate to this position; and
(3) include your current or ending salary.
Starting salary may vary depending on qualifications and experience of the selected candidate.
(1) specifically outline the reasons for your interest in the position;
(2) outline your particular skills and experience that directly relate to this position; and
(3) include your current or ending salary.
Starting salary may vary depending on qualifications and experience of the selected candidate.
Job Summary
Information and Technology Service (ITS) is seeking an experienced Cloud Sourcing Manager to oversee cloud computing activities at the University of Michigan. This solution oriented, flexible and proactive manager will be responsible for working with key process stakeholders such as Procurement Services, Office of General Counsel and IT governance groups to establish effective, secure and sustainable cloud sourcing processes for IT-related activities.
NOTE: this position is funded for 1-year.
NOTE: this position is funded for 1-year.
Responsibilities*
*Maintain a broad understanding of cloud marketplace including Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) offerings.
*Manage relationships with cloud vendors including establishing service level standards and reporting.
*Participate on and/or lead project teams that are leveraging new cloud-based products.
*With appropriate stakeholders, support contract negotiation with cloud providers.
*Serve as a single-point-of-contact for cloud-related issues for the campus community.
*Oversee the creation and maintenance of business processes that support the acquisition, operation and retirement of cloud services such as templates and instructional material.
*Work with Information and Infrastructure Assurance (IIA) to encourage and ensure the use of cloud services follow appropriate security, compliance and privacy standards.
*Accelerate the adoption of cloud solutions by removing barriers, streamlining processes and supporting the move to cloud solutions.
*Work with architecture and technical groups to establish technical integration support to allow cloud services to leverage standard directory, authentication and other interfaces.
*Track the use of cloud services and identify trends and investment opportunities.
*Work cooperatively with higher education consortiums to provide and leverage expertise and combined purchasing power.
*Demonstrate effective staff leadership and development.
*Creative problem solving and strong strategic thinking skills.
*Manage relationships with cloud vendors including establishing service level standards and reporting.
*Participate on and/or lead project teams that are leveraging new cloud-based products.
*With appropriate stakeholders, support contract negotiation with cloud providers.
*Serve as a single-point-of-contact for cloud-related issues for the campus community.
*Oversee the creation and maintenance of business processes that support the acquisition, operation and retirement of cloud services such as templates and instructional material.
*Work with Information and Infrastructure Assurance (IIA) to encourage and ensure the use of cloud services follow appropriate security, compliance and privacy standards.
*Accelerate the adoption of cloud solutions by removing barriers, streamlining processes and supporting the move to cloud solutions.
*Work with architecture and technical groups to establish technical integration support to allow cloud services to leverage standard directory, authentication and other interfaces.
*Track the use of cloud services and identify trends and investment opportunities.
*Work cooperatively with higher education consortiums to provide and leverage expertise and combined purchasing power.
*Demonstrate effective staff leadership and development.
*Creative problem solving and strong strategic thinking skills.
Required Qualifications*
*Bachelor's degree in Computer Science, business or related field or an equivalent combination of education and experience.
*Extensive experience with IaaS, PaaS and SaaS services and implementations.
*Broad knowledge of cloud computing marketplace.
*8 years of progressive IT managerial experience.
*Proven project management experience to meet customer expectations and mitigate risk.
*Superb verbal and written communication skills.
*Demonstrated supervisory experience to include: recruiting, mentoring, staff development, performance management, leadership, and/or team building.
*Ability to interact successfully with a wide range of people including faculty, executive leadership, technical staff and other campus groups.
*Strong organizational skills and the ability to successfully complete multiple tasks within established and changing deadlines.
*Extensive experience with IaaS, PaaS and SaaS services and implementations.
*Broad knowledge of cloud computing marketplace.
*8 years of progressive IT managerial experience.
*Proven project management experience to meet customer expectations and mitigate risk.
*Superb verbal and written communication skills.
*Demonstrated supervisory experience to include: recruiting, mentoring, staff development, performance management, leadership, and/or team building.
*Ability to interact successfully with a wide range of people including faculty, executive leadership, technical staff and other campus groups.
*Strong organizational skills and the ability to successfully complete multiple tasks within established and changing deadlines.
Desired Qualifications*
*Masters Degree in business, technology or related field.
*Experience leading IT efforts in a higher education institution.
*Significant experience managing vendor relationships.
*Experience negotiating contracts and managing ongoing service levels.
*Experience leading IT efforts in a higher education institution.
*Significant experience managing vendor relationships.
*Experience negotiating contracts and managing ongoing service levels.
Additional Information
The University of Michigan was featured as one of the "Great Colleges to Work For" in the 2011 Chronicle of Higher Education.
U-M EEO/AA Statement
The University of Michigan is an equal opportunity/affirmative action employer.
Monday, May 14, 2012
Why ask why? (Seth Godin)
- Why is that our goal?
- Why is this our policy?
- Why are we having this meeting?
And I'll add a few more of my own particular to ICPSR:
- Why do we count downloads?
- Why is this the way we curate data and documentation?
- Why do we conduct a disclosure reviews?
- Why are grant budgets very detailed and specific, but the deliverables are completely flexible?
I think "Why?" is a great question.
Monday, August 2, 2010
Motivation and the annual raise
The University of Michigan has an annual rite: Departments and organizations are allocated a pool of money, typically some small fraction of the total salaries in that department or organization, and managers assign some portion of it to each staff member as an annual increase in base pay. The overall increases are not large by any means, and it isn't that unusual for people to view it almost as a cost-of-living increase.
Along this same topic, I've also been reading a book called Drive written by a gent named Daniel Pink. The book is an interesting read and essentially argues that reward-based systems are just great for mechanical, repetitive work, but actually have the opposite effect if the work requires any sort of creativity whatsoever. In particular, when there is a task or project at hand, it kills performance when there is some type of "IF-THEN" statement made up front, like: "IF you deliver the solution quickly and correctly, THEN you will get a bigger reward." He makes a pretty compelling case.
There's a nice video from TED where Pink presents the core argument from his book too. He's a good speaker, and even if you've read the book, the video is also worth watching.
And so I've been thinking about how Pink's advice in Drive relates to this annual rite at Michigan.
One possible scenario is that Pink is right, and instead of differentiating raises across different staff, everyone should just get the same increase. All of the tech staff are doing creative work on a daily basis, and since we know cash incentives result in worse performance, that makes the most sense.
Another possible scenario is that Pink is still right, but because this process occurs only once per year, the relationship between the performance on any one job or task is almost wholly unrelated to the increase. I cannot think of a single time where I based an annual increase on a single project or task. And because the increase does not take the form of "IF you do a good job on project X, THEN you will get a better raise", maybe it doesn't apply? Maybe the raise is really saying, "BECAUSE you did such a good job on so many different things over this past year, we're recognizing this with a higher increase"?
He does go on to say that when a reward is given after the fact, and is unexpected, this does have the anticipated result, and is motivating. Maybe a higher annual raise is more like this - unexpected, and more like a thank you?
Along this same topic, I've also been reading a book called Drive written by a gent named Daniel Pink. The book is an interesting read and essentially argues that reward-based systems are just great for mechanical, repetitive work, but actually have the opposite effect if the work requires any sort of creativity whatsoever. In particular, when there is a task or project at hand, it kills performance when there is some type of "IF-THEN" statement made up front, like: "IF you deliver the solution quickly and correctly, THEN you will get a bigger reward." He makes a pretty compelling case.
There's a nice video from TED where Pink presents the core argument from his book too. He's a good speaker, and even if you've read the book, the video is also worth watching.
And so I've been thinking about how Pink's advice in Drive relates to this annual rite at Michigan.
One possible scenario is that Pink is right, and instead of differentiating raises across different staff, everyone should just get the same increase. All of the tech staff are doing creative work on a daily basis, and since we know cash incentives result in worse performance, that makes the most sense.
Another possible scenario is that Pink is still right, but because this process occurs only once per year, the relationship between the performance on any one job or task is almost wholly unrelated to the increase. I cannot think of a single time where I based an annual increase on a single project or task. And because the increase does not take the form of "IF you do a good job on project X, THEN you will get a better raise", maybe it doesn't apply? Maybe the raise is really saying, "BECAUSE you did such a good job on so many different things over this past year, we're recognizing this with a higher increase"?
He does go on to say that when a reward is given after the fact, and is unexpected, this does have the anticipated result, and is motivating. Maybe a higher annual raise is more like this - unexpected, and more like a thank you?
Saturday, September 12, 2009
ICPSR: Then and Now: Technology Human Resources: Part II
As I mentioned in the last post, the team faced two main challenges in 2002: How to grow its capacity for managing IT resources without adding more people; and, how to expand its capacity for delivering solutions, and becoming a true partner at ICPSR.
We addressed the first challenge by asking our administrative assistant to step into a technology support role. This transition was largely successful, but when the administrative assistant retired at the end of 2005, we refilled the position with someone who had already been working in the IT sector. We also made one new hire in this area, adding Asmat Noori as as assistant IT director with responsibility for operations. Asmat's team supports over twice as many systems as 2002, and his introduction of tools such as Altiris and Wise has allowed us to keep the size of the team the same. That said, we're hoping to use a Challenge Grant to fund a new person who will lead ICPSR's adoption of cloud computing and cloud storage technologies.
We addressed the second challenge through a combination of writing grants and contracts, and recruiting software developers with expertise and experience in technologies such as Java. We also encouraged internal ICPSR businesses, such as the Summer Program, to fund directly portions of software developers when there is a need for sustained development and enhancement, such as the new Summer Program Portal.
This has been a very successful combination with new software developers joining the team in 2003 (to work on the Child Care and Early Education Research Center project), 2005 (to automate key data processing and data pipeline work flows at ICPSR), 2007 (one to build tools for the Minority Data Resource Center and one to build the Summer Program Portal), and 2008 (to build technology for the Quantitative Social Science Digital Library). Because the software development team had become so large and worked with so many partners across ICPSR, we also hired an assistant director for software development, Nathan Adams, in late 2008.
Cole Whiteman joined ICPSR in 2004, and brought his skills of process forensics to our data management activities. Cole later joined the Computer and Network Services team, and continues his work to analyze processes and build software systems. Cole built and support systems for managing most of our metadata and the deposits that arrive via our on-line deposit system.
And Peter Joftis returned to his technology roots, re-joining the CNS team in 2009 after leading the Child Care and Early Education Research Center project for the past six years. Peter's current focus is on CCEERC content, and how best to store it in a Fedora repository.
And so the story ends, for now, in 2009 with an IT organization that looks very different.
Like in 2002 it still manages and operates ICPSR's considerable technology infrastructure, and despite the growth in those assets, does so with just about the same number of people as in 2002.
However, in 2009, the number of software developers has grown from two to eight, and the capacity to work in a broad array of technologies has increased dramatically. Also, its ability to work with stakeholders at ICPSR to analyze processes, design solutions, co-write grant applications, and deliver new products and services has grown even more.
We addressed the first challenge by asking our administrative assistant to step into a technology support role. This transition was largely successful, but when the administrative assistant retired at the end of 2005, we refilled the position with someone who had already been working in the IT sector. We also made one new hire in this area, adding Asmat Noori as as assistant IT director with responsibility for operations. Asmat's team supports over twice as many systems as 2002, and his introduction of tools such as Altiris and Wise has allowed us to keep the size of the team the same. That said, we're hoping to use a Challenge Grant to fund a new person who will lead ICPSR's adoption of cloud computing and cloud storage technologies.
We addressed the second challenge through a combination of writing grants and contracts, and recruiting software developers with expertise and experience in technologies such as Java. We also encouraged internal ICPSR businesses, such as the Summer Program, to fund directly portions of software developers when there is a need for sustained development and enhancement, such as the new Summer Program Portal.
This has been a very successful combination with new software developers joining the team in 2003 (to work on the Child Care and Early Education Research Center project), 2005 (to automate key data processing and data pipeline work flows at ICPSR), 2007 (one to build tools for the Minority Data Resource Center and one to build the Summer Program Portal), and 2008 (to build technology for the Quantitative Social Science Digital Library). Because the software development team had become so large and worked with so many partners across ICPSR, we also hired an assistant director for software development, Nathan Adams, in late 2008.
Cole Whiteman joined ICPSR in 2004, and brought his skills of process forensics to our data management activities. Cole later joined the Computer and Network Services team, and continues his work to analyze processes and build software systems. Cole built and support systems for managing most of our metadata and the deposits that arrive via our on-line deposit system.
And Peter Joftis returned to his technology roots, re-joining the CNS team in 2009 after leading the Child Care and Early Education Research Center project for the past six years. Peter's current focus is on CCEERC content, and how best to store it in a Fedora repository.
And so the story ends, for now, in 2009 with an IT organization that looks very different.
Like in 2002 it still manages and operates ICPSR's considerable technology infrastructure, and despite the growth in those assets, does so with just about the same number of people as in 2002.
However, in 2009, the number of software developers has grown from two to eight, and the capacity to work in a broad array of technologies has increased dramatically. Also, its ability to work with stakeholders at ICPSR to analyze processes, design solutions, co-write grant applications, and deliver new products and services has grown even more.
Thursday, September 10, 2009
ICPSR: Then and Now: Technology Human Resources: Part I
When I joined ICPSR in 2002 the technology team - called Computer and Network Services - had eight people. In addition to myself, there was an administrative assistant, two software developers, three systems administrators, and one technology generalist who did a little bit of everything. Longtime ICPSR staffer Peter Joftis was also on the team, but soon left to lead ICPSR's Child Care and Early Education Research Center.
The team managed about 75 desktop workstations, a small number of servers, the local area network (LAN), a dozen or so printers, and no doubt a handful of other technology assets I've lost track of over time. With only two software developers the team spent most of its time delivering incremental changes to the web delivery system, and tending to core infrastructure, such as our database and web applications for managing information about the membership. At the time we were very much a classic IT shop.
People worked very hard, but we were on the margin of the business. And we were perceived that way. The IT people were the ones who fixed your PC when it had a virus. They patched computers when Microsoft announced yet another security flaw in Windows or Office. They took care of backups, and retrieved that file you deleted accidentally. These were valuable services to be sure, but they weren't core to the business. They don't think up solutions to our problems; they just implement the technology solutions we think up. We were not partners.
Because ICPSR is so clearly in the information business, but made almost no entrepreneurial investments in information technology, 2002 was a very dangerous time for the organization. But what to do?
When interviewing for the position it was clear that the team fell into two distinct functional subgroups. One group delivered those classic IT support functions, and the other group delivered new products and services.
It would be important for the first group to remain about the same size, but expand its capacity to support more of everything: more servers, more storage, more desktop workstations, more printers, etc. And so we would need to invest in tools and processes to build this capacity without adding significantly to the number of people on the team.
And it would be important for the second group to grow. A lot.
One, it would need to be a bigger team. The capacity to deliver new products and services, to explore new technologies, and to automate the many manual processes at ICPSR all needed to be expanded dramatically.
Two, it would need to be a more partner-oriented team. The team needed to expand its ability to work hand-in-hand with data processors, archive managers, and grant writers to understand key business problems and opportunities, and to recommend and build solutions to address those needs. Many of the software developers would need to become project managers and systems analysts.
And, three, it would need to expand its repertoire of technologies. The team had been working largely in CGI/Perl to build web applications, and Perl alone to build command-line utilities, and those were the appropriate, dominant technologies of the 90's. But by 2002 there were many other technologies available, and the team needed to select the best, and build its collective muscle around them.
Next: The team evolves
The team managed about 75 desktop workstations, a small number of servers, the local area network (LAN), a dozen or so printers, and no doubt a handful of other technology assets I've lost track of over time. With only two software developers the team spent most of its time delivering incremental changes to the web delivery system, and tending to core infrastructure, such as our database and web applications for managing information about the membership. At the time we were very much a classic IT shop.
People worked very hard, but we were on the margin of the business. And we were perceived that way. The IT people were the ones who fixed your PC when it had a virus. They patched computers when Microsoft announced yet another security flaw in Windows or Office. They took care of backups, and retrieved that file you deleted accidentally. These were valuable services to be sure, but they weren't core to the business. They don't think up solutions to our problems; they just implement the technology solutions we think up. We were not partners.
Because ICPSR is so clearly in the information business, but made almost no entrepreneurial investments in information technology, 2002 was a very dangerous time for the organization. But what to do?
When interviewing for the position it was clear that the team fell into two distinct functional subgroups. One group delivered those classic IT support functions, and the other group delivered new products and services.
It would be important for the first group to remain about the same size, but expand its capacity to support more of everything: more servers, more storage, more desktop workstations, more printers, etc. And so we would need to invest in tools and processes to build this capacity without adding significantly to the number of people on the team.
And it would be important for the second group to grow. A lot.
One, it would need to be a bigger team. The capacity to deliver new products and services, to explore new technologies, and to automate the many manual processes at ICPSR all needed to be expanded dramatically.
Two, it would need to be a more partner-oriented team. The team needed to expand its ability to work hand-in-hand with data processors, archive managers, and grant writers to understand key business problems and opportunities, and to recommend and build solutions to address those needs. Many of the software developers would need to become project managers and systems analysts.
And, three, it would need to expand its repertoire of technologies. The team had been working largely in CGI/Perl to build web applications, and Perl alone to build command-line utilities, and those were the appropriate, dominant technologies of the 90's. But by 2002 there were many other technologies available, and the team needed to select the best, and build its collective muscle around them.
Next: The team evolves
Monday, June 15, 2009
It's that time of year again....
It's June and at ICPSR that means it's nearing the end of another quarter and also the end of the 2008-2009 fiscal year. And that means it's time to start writing formal performance reviews, and to create the formal work plans for next year.
I've worked at a lot of different places, managed many different types of technology groups, and used different mechanisms for this activity. At our start-up software company, almost nothing was written down; at the UUNET portion of MCI Worldcom the process was surprising lightweight - everyone was just a number in a spreadsheet; and at ICPSR the process is more heavyweight.
Each had it's virtues and vices, but a heavyweight process requires more writing, and more careful thinking. If one is distilling performance over the past year into a digit between 1 and 4, then the "writing" aspect it pretty easy; if one is writing a handful of paragraphs about the person's performance over that same time period, it takes a lot more time and thought.
There are a lot of different ways to measure performance, but for my money the best performers demonstrate their value to the organization in the following seven ways. Sometimes you'll have that rare person who shows four, five, maybe all seven of these characteristics, and my bet is that they're your top performer.
Quantity. Whether its troubleshooting network problems, solving desktop or server issues, or writing code, the top performers are the people who get a lot of stuff done. They don't sacrifice quality for quantity, and they do the little things right like commenting their code or tickets, and making sure they've left behind a good trail that others can follow. When they take a vacation the rest of the team groans because they know they'll have to pick up a ton of slack.
Quality. These are the people that write the applications that look great and work just like you'd expect them to work. Their stuff is good, and intuitive to use. They are the people that really come to understand the appropriate technology and standards, and they solve the problem once and for all. They don't use a band-aid when major surgery was the necessary solution. (Or vice-versa.) Once they fix it or write it, it just works.
Flexibility. Knowing one thing well is useful. Knowing one thing really, really well is really useful. Knowing a lot of different things reasonably well is gold. Having the attitude to say, "Well, I don't know how to do that using X, but I'll go find out." If I can only give a certain kind of project to someone on the team, then their usefulness and ability to contribute is really constrained. If I can throw almost anything at them, then their value to me is huge.
Knowing the business. Someone who really understands what the business is, how it makes its money, how its key processes operate, and how the major pieces fit together is essential for certain types of problem-solving. These are the people who can tell that something isn't quite right, and they dig into the business and people processes to find out what's really wrong. And then they fix that thing, not the symptom. It takes a while for new staff to really get good at this, but it is a critical area for their growth and development. It keeps them in the core of the business, and makes them a partner in its success.
Teaching. Key staff are good teachers. They teach themselves new technologies. They teach their peers new ways of solving old problems. They teach their managers about new developments in technology and problem-solving. They email you links to articles or blog posts or book reviews that are interesting and timely. They teach their colleagues and customers why something broke, and how they fixed it. They learn stuff well enough that they can teach others about it, and they have the patience and skills to explain things in a lucid, disarming manner. They are like MVP point guards in basketball: they make the whole team better.
Writing. Good writers help the whole organization. They write clear comments in code and tickets. They post illuminating and interesting content in blogs, wikis, and support forums. They put together good information to share with the boss (theirs and mine). They can put together those "all organization" emails that explain clearly and concisely what sort of maintenance is going to happen next week at 6am, or why the server blew up yesterday at noon. They don't just forward that long email; they annotate it with two sentences that deliver the punchline, inviting you to read the whole thing if you want to see the details. You make time to read their long emails because you know it's long for a good reason.
Asking for help. No one knows everything about everything. There is always a time when someone gets stuck with a problem, whether it's interpersonal, technical, political, or other. The top people know when they've stopped making progress and are spinning their wheels. Instead of waiting for the boss to notice, poke into the situation, and then call for relief, they contact the boss first. Or one of their colleagues. Or the customer. The point is that they know when to reach out to others in order to finish the job. Their ego is strong enough that they aren't afraid to say "I don't know."
I've worked at a lot of different places, managed many different types of technology groups, and used different mechanisms for this activity. At our start-up software company, almost nothing was written down; at the UUNET portion of MCI Worldcom the process was surprising lightweight - everyone was just a number in a spreadsheet; and at ICPSR the process is more heavyweight.
Each had it's virtues and vices, but a heavyweight process requires more writing, and more careful thinking. If one is distilling performance over the past year into a digit between 1 and 4, then the "writing" aspect it pretty easy; if one is writing a handful of paragraphs about the person's performance over that same time period, it takes a lot more time and thought.
There are a lot of different ways to measure performance, but for my money the best performers demonstrate their value to the organization in the following seven ways. Sometimes you'll have that rare person who shows four, five, maybe all seven of these characteristics, and my bet is that they're your top performer.
Quantity. Whether its troubleshooting network problems, solving desktop or server issues, or writing code, the top performers are the people who get a lot of stuff done. They don't sacrifice quality for quantity, and they do the little things right like commenting their code or tickets, and making sure they've left behind a good trail that others can follow. When they take a vacation the rest of the team groans because they know they'll have to pick up a ton of slack.
Quality. These are the people that write the applications that look great and work just like you'd expect them to work. Their stuff is good, and intuitive to use. They are the people that really come to understand the appropriate technology and standards, and they solve the problem once and for all. They don't use a band-aid when major surgery was the necessary solution. (Or vice-versa.) Once they fix it or write it, it just works.
Flexibility. Knowing one thing well is useful. Knowing one thing really, really well is really useful. Knowing a lot of different things reasonably well is gold. Having the attitude to say, "Well, I don't know how to do that using X, but I'll go find out." If I can only give a certain kind of project to someone on the team, then their usefulness and ability to contribute is really constrained. If I can throw almost anything at them, then their value to me is huge.
Knowing the business. Someone who really understands what the business is, how it makes its money, how its key processes operate, and how the major pieces fit together is essential for certain types of problem-solving. These are the people who can tell that something isn't quite right, and they dig into the business and people processes to find out what's really wrong. And then they fix that thing, not the symptom. It takes a while for new staff to really get good at this, but it is a critical area for their growth and development. It keeps them in the core of the business, and makes them a partner in its success.
Teaching. Key staff are good teachers. They teach themselves new technologies. They teach their peers new ways of solving old problems. They teach their managers about new developments in technology and problem-solving. They email you links to articles or blog posts or book reviews that are interesting and timely. They teach their colleagues and customers why something broke, and how they fixed it. They learn stuff well enough that they can teach others about it, and they have the patience and skills to explain things in a lucid, disarming manner. They are like MVP point guards in basketball: they make the whole team better.
Writing. Good writers help the whole organization. They write clear comments in code and tickets. They post illuminating and interesting content in blogs, wikis, and support forums. They put together good information to share with the boss (theirs and mine). They can put together those "all organization" emails that explain clearly and concisely what sort of maintenance is going to happen next week at 6am, or why the server blew up yesterday at noon. They don't just forward that long email; they annotate it with two sentences that deliver the punchline, inviting you to read the whole thing if you want to see the details. You make time to read their long emails because you know it's long for a good reason.
Asking for help. No one knows everything about everything. There is always a time when someone gets stuck with a problem, whether it's interpersonal, technical, political, or other. The top people know when they've stopped making progress and are spinning their wheels. Instead of waiting for the boss to notice, poke into the situation, and then call for relief, they contact the boss first. Or one of their colleagues. Or the customer. The point is that they know when to reach out to others in order to finish the job. Their ego is strong enough that they aren't afraid to say "I don't know."
Subscribe to:
Posts (Atom)