A recent tweet from the always erudite and curious Peter Seibel prompted a long discussion on Twitter, followed by an excellent summary/recap on his blog and minor rebuttal from my friend Luke Andrews. Both make excellent points, and I found a lot to agree with in both posts. That being said, this is a complex set of issues, so I wanted to throw my own perspective out there as well.
First and foremost, I agree 100% with Peter's assertion that scheduled, formalized feedback must not be a substitute for regular conversations between managers and their teams about career development and goals. As a manager you need to educate your team on how planning and career growth happens at your company and advocate for them when they're ready for promotion, no matter whether it fits nicely into a larger process or schedule.
Luke also appropriately calls out the distinction between authority or responsibility and accomplishment. Awesome team members will often do things worthy of recognition without being expected to; only sometimes does this result in that becoming an ongoing part of their role and responsibilities.
Rather than join in the chorus of complaints about existing systems (especially Twitter's) though I thought I'd offer the process I helped to develop up as a counterexample.
So, here's the summary:
When I joined Urban Airship I actually got the opportunity to write a new set of job descriptions for engineering staff and define a promotion process. I had two main goals in doing so: systematize and document the ad-hoc and poorly-understood process for promotion, and give guidance for the behaviors and responsibilities expected of both managers and individual contributors.
The company already had an annual review process in place, but promotions were largely tied to changes in org chart (i.e. increased supervisory scope) rather than goal-setting and accomplishments. After a great deal of back-and-forth with our HR department and executive team, I got approval to run two "promotion cycles" per year: one following closely after the company-wide annual review period and the other roughly six months later.
That separation allowed managers to collect different data points for the "official" HR review – focused on self-assessment and goal-setting and the promotion proposal. The latter was a brief showcase of the promotion candidate's performance in each area described in our tech ladder as backed by peer and manager feedback, without an individual argument from each person for their own promotion. Most people know they're being submitted for promotion, but the process doesn't require it.
Promotions are reviewed at the Director and executive level, and while the number approved is largely at the discretion of the engineering team, the overall budget for the associated compensation budget is controlled by HR and finance.
This fits some of the criteria Peter and Luke laid out for an improved review system, though not all: self-assessment is decoupled from promotion review; management scope and contribution are recognized along different axes; and the there's a clear chain of accountability for the decisions (i.e., no "secret council" acting outside the management chain).
There are also areas where it fails to improve on or meet their legitimate criticisms: the schedule isn't completely fluid; the tech ladder and job titles have to explicitly encode the kinds of accomplishments you want to reward; and compensation changes for merit, market adjustment, and title changes tend to get lumped together in most people's minds.
I'm pretty happy with this as a version 1.0. Of course, if other people have better ideas (esp. ones they've actually tried in the field) I'd love to hear about 'em.
One of the ways that my chosen field of software development is different from many others is that we've had a major problem over the last few years hiring enough people. Compared to the wider economic narrative of disruption, offshoring, and automation this leads to a skewed (at least compared to other industries) view wherein we want to hire tons of people and have to then fight like hell to keep them.
Retention is a topic worth its own series of blog posts (which I hope to start on some time soon) but I think that first hiring conversation is important enough to talk about on its own.
Given the competitive market for skilled software engineers, many people try to steer every qualified candidate towards their company/team as quickly as possible. It makes sense, right? Why give someone time to consider their options when you need their help ASAP?
Taking the long view, I think an aggressive stance is counterproductive, especially early on. Every conversation with a candidate (active or passive) is a chance to meet a new potential colleauge and develop a business relationship, no matter how ephemeral.
There's always plenty to talk about: your company and team; the industry as a whole; and what they hope to find in their next job. Hell, talk about food and music if that seems to be where the conversation is headed.
If after all of that you feel like there's a mutual interest in possibly working together then start the pitch for your current opening.
Important note: this is not a remit to pick people who think like you, talk like you, and look like you. Your colleagues should be appealing because they stretch and challenge your perspective and assumptions, not because you went to the same grad school. Why hire someone who's just going to redundantly say the things you would say in every meeting/code review/email thread?
One major upside of this kind of discussion is that I at least feel less like a salesman and more like a peer. Rather than try to steer the conversation towards topics I think will paint the position I'm hiring for in a good light, I get to chat generally about the industry and local tech scene. It's not only more fun, I tend to learn more from prospective hires this way than I ever could in a more traditional interview.
Last week I changed jobs...sort of.
I'm now working part-time at Reed College starting up a new software development training program for students. I'm also still working at Urban Airship, though I won't be managing anyone directly. Reed is actually the place I've worked the longest in my career to date, so this is equal parts new job and homecoming.
I was motivated to make this change for a bunch of reasons. First, the program at Reed (which I will talk about a lot more soon) is incredibly interesting and fairly unique. I've been working to see it happen for a long time now, so when the opportunity to take on a direct staff role came along I couldn't pass it up.
Second, the engineering team at Urban Airship is on a much different footing than it was 15 months ago. We've weathered some significant technical and organizational challenges and emerged a much stronger, tighter-knit group. I had a lot of fun getting to this point, but it's also been a busy and at times stressful process and I'm happy to let a new leader take the team forward.
I've also been working with a bunch of people over the last year or so to improve access to technology jobs through my hiring role at Urban Airship. This new program is a natural extension of that goal.
P.S.: If you're a Reedie in tech and I haven't already talked to you about mentoring or otherwise helping out with this new program, please reach out.
P.P.S.: This also means I'm blogging again. So far it's just static HTML on my web server, but I'll try to get some RSS goodness up soon.