On Managing Developers

I love the comments in Jon Evans' On Managing Developers.  The disagreements and arguing get to the heart of why it's often a crazy job.  No two people expect the same manager as their optimal manager.  I'm often in the position where I operate under "This is what makes sense right now" for a team.  There are a few things that are common project to project, but most projects have a unique flavor and unique personalities that require flexibility, communication, and quick personal iterative cycles above other skills.

Dianne Marsh at Netflix

I liked this extract from her interview (11 minutes):

"Charles full question: Something I know from listening to you present, and also talking to Adrian Cockroft and people like that, is basically Netflix was designed for speed of execution essentially; to get things done really quickly. So from a kind of people point of view, what are some of the things that slow people down and what do you look for and try and take out of the process?

Yes, you are right. What we want to be able to do at Netflix is push things out really quickly: keep people moving. A manager’s role at Netflix is really just to get out of the way, you know hire really great people and get out of the way. I think what a lot of companies make the mistake of doing is hiring really great people and then putting a lot of processes in their way and a lot of gates that actually slow them down, or question the direction that those people want to take; and instead we really want those people to do what we hired them for, and frankly what we pay them for, which is just to build great software; and so a manager’s job at Netflix, my job at Netflix, is to make sure that I give my team context about what the rest of the company is doing, and give context about what my team is doing to the rest of the company, so that we can all make great decisions together about what to do. I get out of the way of the decisions that my team make, so that they can independently come up with great ideas, and I don’t have to stand in the way and decide which things have legs and which things don’t. Instead I just depend on the wisdom of the people that we hire to be able to make those decisions."

Peformance, Trust, and Hiring

Recently I had my first team meeting with my new team.  Not so new now - I've been with them for a quarter, but in my experience even with a team where you know most of the developers it takes a quarter to understand the personalities and whether their goals and desires have changed since you last worked with them (and some of them I haven't worked with in almost three years).

I had a plan for the meeting, but I’m flexible and have lots of backup directions. Partially because my plans: talk about larger organizational theoretical topics, talk about Javascript visualization packages (although JS Sequence, cool...), talk about corporate/code security; can sometimes feel like lecturing rather than responding.  So after a few minutes of Q&A we went with flexible instead of planned and talked about team questions (culture, dev and test merging under a project aspect, am I moving closer to the team space [I currently sit two floors up and a tenth of a mile away - seriously], annual reviews/ratings and why you should give them some serious attention, etc) for 40 minutes.

I was sort of glad I didn't have to stick to my original plan.  A couple of team members asked “what’s that?” as regards culture changes, artifacts, and corporate statements.  I had a couple of videos that seemed somewhat culture change centric that had been in my planned queue.  I’d read a really good article by Derek Sivers on great customer service in my PragProg magazine (I know, I know, it's the Prose Garden now) – focused more on a culture of customer service, but interesting - and knew he had TED talks, so it included the following by him and these two others about corporate culture and safety.

• http://www.ted.com/talks/derek_sivers_how_to_start_a_movement?language=en
• http://www.ted.com/talks/dan_ariely_what_makes_us_feel_good_about_our_work
• http://www.ted.com/talks/simon_sinek_why_good_leaders_make_you_feel_safe#t-9553

Sivers was funny, but it's the Sinek one that strikes a little close to home in a culture discussion.  You don’t need to watch it – I’ll boil it down.  He says our tribal nature as humans encourages us to be safe within a particular group and see other, outside, things as a threat.  In any culture, that’s what you’re working against (the group identified as “safe” vs. everything outside “safe”).  As an example of a culture that tries to break down that safety circle and redefine it in terms of the company (widening the safety/trust circle is an alternative way to look at it), he refers to a company that hires for life, NextJump.  They have a incredibly in-depth onboarding process with the end result being you can’t get fired.  They can make you miserable (I assume) and put you through tons of training and re-training, and the company could go bankrupt, but the basic philosophy of the company is you’re hired for life or as long as you want to be (hired, not alive).  You can now ignore the threat of losing your job as an issue – you’re safe/r.  The whole company is your tribal safety space.

This leads to unpleasant questions…is there a basic disconnect between our pay for performance cultural practice and our desired cultural reality at my own employer?  If team members have to worry that not only is their performance potentially an issue, but that it’s subject to influences such as the opinion of specific managers and bell curves (basic math), are we sending two different messages about our culture?  Or creating a schizophrenic culture where we ask for trust that we potentially might not be giving?  You can intuit out some of my thoughts on it from my questions – but at the moment, I’m mulling it over and trying to decide if I think our cultural change isn’t thought out enough to tackle the shift on all levels and from all angles (and whether that dooms it to fail).  I need to think it through a bit more before I'm willing to dig into the topic with a group so that I'm not grinding my ideas against my team.

Snarky Reboot

Snrky.com has rebooted! You can probably see the picture/link on the right of this blog, but in case it's too small, the art is brand new.  The site is temporarily moving to five posts a week while it reposts three of the originals each week and posts two new cartoons as well.  There are even some new frames that will be showing up.  It finally looks like something that could be put on the side of a coffee cup or on a wall.

Automated Regression Testing

Per the modern definition of "legacy code", my new projects (which I've had for six months) are legacy. No automated regression. No continuous integration. No unit tests. It should be left unsaid that the next time someone says, "We want you to take this project and own it," my response will be, if it doesn't have a.), b.) and c.), you will provide me a budget for software and the necessary resources of at least a certain level based on the age of the project and the scope of the code to implement those things, or I'm not interested. Live and learn. I spent part of tonight playing around with Watin, Selenium, iMacros, and TestComplete. Most of those don't actually target desktop applications, which is what I'm after, but it's interesting to fool around with the tools and see what I can accomplish. I had someone else ask me about the possibility of pulling a mailing list from the web, and using a testing tool that can be extended to write to a file using javascript or C# (actually any language, but those are my sweet spots) works perfectly in that case.

Not very managerial, but then neither is automating the scripts for open source analysis, analyzing code for security holes, or config-developing the tools necessary to poc the new open source jars.

What is managerial is that the developer I've been trying to promote for several months got his promotion to Lead Software Engineer today.  He's been a lead for other LSE's (2-3 depending on the time frame) for the last 12 months, so it was way overdue.  Proof that working for a big company with some golden handcuffs can still pay dividends depending on your goals if you step up when no one else will.  He earned the promotion and I'm excited to see him landing not only the change in title, but a raise, and a potential award (with cash) in the near future.

Software Links III

Get the idea that I spend a lot of time reading about software lately? The iPad helps immensely. If you have one, I recommend Zite, the programming category is great, particularly after it starts to get a read on what you're interested in. Not perfect, but still good.

• How to Create a Killer Ignite presentation - our submission of how to do your own stick figure comic was denied, although we're pulling together better art. Some other options are CMSes and Dytopias. We're going to queue up a few of our ideas and make sure we're ready to go next time with some options. I should speak in front of audiences a bit more - I'm not known for being a stand up commedian.  If you haven't heard of Ignite! there are plenty of videos at that link, plus some at the YouTube tag.  The videos from the most recent event (#3/2011) aren't out there yet.
• I didn't know until I bought a PDF book from them that Pragmatic Programming had a magazine (online).  There are really good articles out there on Agile at 10, Refactoring Your Job, HTML 5, Writing a Book for Pragmatic, and a slew of other great content.
• Work is Fascinating: the Metagame - speaking of "refactoring your job" (nice...I have transitions in my links, they're like an iTunes playlist), Mark O'Connor talks about optimizing his job to keep himself interested and only busy with the most enjoyable things.  In the spirit of Peter Drucker's books, he recommends aggressively eliminating all repetitive tasks so that you can focus on what's innovative and makes your brain work.  How he specifically goes about it might not be everyone's cup of tea (I'm still not going to use Vim), but the basic ideas speak to find tools to eliminate wasted time, find opportunity to do what's fun in new ways ("Write in all the fun languages you can’t use at work"), measure it, and do it immediately.  That most of the advice you need to make your job tolerable (the other bit being, in my experience, just take it easy, relax, enjoy the change and enjoy the people).
• Moshidora - a graphic novelized application of Drucker (see, transitions...told you so).  I'm looking forward to getting my hands on an English version some day.  Reminds me of Dan Pink's Johnny Bunko: the Last Career Guide You'll Ever Need which is one of the few management books sitting on my shelf at work (signed copy, thank you Dan).  I just recently recommended it to two high school students I'm mentoring via BestPrep.  If I'd have been planning better, I'd have had two copies available when they came to visit.  I'll be better prepared next year.
• Speaking of Dan, he recommended Leadership is Dead some time ago on Twitter.  I'd like to skim it, despite at least one assertion that there's nothing new involved in the work.  My stint as a Large Database Partner Consultant for our corporate proprietary database involved leading by influence and it's my experience that in a large company, on any large project, there's almost always a lack of leadership somewhere that can be filled indirectly by someone with the skill.  While looking at Amazon's Leadership is Dead page, it was recommended that I read Poke the Box, which has a Q&A section that includes: "Question: What does it mean to Poke the Box?"  Nice.  I like the part where it says Poke the Box may be the kick in the pants I need.  I bet if I poke enough boxes, I'd get a whole bunch of kicks in the pants.  Just not the back side.
• And, speaking of things that made me laugh in the management/career space, this article about Leveling Up: Career Advancement for Software Developers by Peter Lyons has an amusing first bit of "Duh" advice, "Don't Annoy Management."  I enjoyed the bit about "watch your language."  I used a bit of profanity at work twice last week.  It's not going to be a habit, but I had two people I wanted to break out of their normal perception of me.  One I've known to use swearing before and I think he thinks I'm a bit of a conundrum, not showing enough urgency on the one hand and a little too straight laced and traditional management on the other.  In that case, the swearing was to convince him, a.) I was passionate about our software, and b.) definitely not tied to management protocol in all situations.  In the second case, it was with someone down chain (how's that for management speak) who I think perceives me as the typical manager to be avoided and who will avoid you if you avoid him, and who doesn't care about what you're working on as long as some things get done for appearances sake.  That time it was for a bit of shock value.  Hopefully I won't be writing about getting called into HR in my next post. And this advice is golden, "Make sure management hears your name in a positive light." I've been telling my new team for months that it doesn't just apply to management.  The department (and beyond) needs to hear your name in a good light, and if that means pimping your own name, filling out your own award forms, telling your manager when s/he doesn't understand your contribution, or even finding a buddy so that you can promote each other, then that's what it takes if you're aiming for something inside the company.  It's advice I wish I had understood more completely when I was an MTS2.  Anyway - I think Peter overdoes it a bit, but his core message is solid, if you want to level up, there are ways to go about it, particularly in a large corporate culture, and you if understand where to apply that effort without appearing mercenary, unless you run afoul of management (speaking from experience), the path upward is in your own hands.

Taking Up Space

I was reading the Harvard Business Review (this month) and there was an article about how leaders - e.g. anyone put in a leadership position - can lie more convincingly than those without power. Not only are they simply more glib, but they produce less cortisone (on the tongue), their eyes dilate less, and they half-shrug less (plus a few other indicators). They exhibit lying behaviors only 1/3 as much as those who don't "have power". Coupled with the fact that you, yes you, can only detect a lie 50-60% of the time, this means your boss can seriously yank your chain and you don't know the difference.

Coupled with this was a nice explanation that those in leadership positions also exhibit physical characteristics such as putting their hands behind their heads in meetings because it's similar to how a peacock takes up more space to show dominance/breeding viability. So when I'm in a meeting, and I put my leg across my other leg and lean back, I'm telling you I'm the fucking biggest peacock in the room and you should want to mate with me. Crap. I've spent the last two days being paranoid about how I sit and how others sit, and evaluating whether I can sit leg up, or should be leg down. If you sit leg up in a meeting with me, I'm calling you out.

Competency

My lead developer on a project couldn't attend a meeting on Friday. My lead (a project manager) couldn't attend in her stead. I said I'd be there. At which point one of the PMs on the project sent a message to me and the project team that said, and I barely paraphrase, "Are you sure you understand all the details involved in the project and can speak to our concerns?" I responded with a four point treatise that basically said, "I wouldn't have done it the way you did it in the first place, so I don't understand what you're doing or why you're doing it, but I understand the project." My lead/PM was highly amused and sent me a one word email that said, "Solid!"

The follow up meeting involved two of the PMs on the project (from the same team) voicing differences in direction in the meeting, arguing with automated testing about whether they'd take the testing tool development we'd been trying to give them all along, talking over the automated testing rep when he was trying to explain that he'd take it (instead of just saying f*ing thank you), questioning how the automated testing team wanted to implement the tool (at which point I spoke up and said, he/she who owns the tool owns the implementation. If it doesn't do what you want, then you go back to the table, but they'll understand it enough to remedy the problem at that point. Until then, tell them what you want in concrete terms and leave the details to the people with the developers), and sounding very confused when they discovered I can pull document ids at will with only 60 minutes of programming (no one ever thinks a manager knows how to use a product api). Possibly the most aggravating meeting I've been in since I started managing, and I've been in a LOT of meetings.

I miss just coding to make myself happy.

Rating as a Team

(My reviewer says I shouldn't xb this one. It seems harmless, but I think I'm going to listen to the advice and give it an xb so I can find it in conjunction with similar posts, but not actually cross-blog it. I pushed enough buttons this week that I should take a breather. So here's a story about annual reviews. Not necessarily about my company, but about something I've seen at big companies, having worked at a few).

If you're reading this for some Agile insight, I have to ask you to bear with me until nearer the end. It's a very roundabout dig into how I feel about a topic that's at odds with Agile based on some recent experiences. But it's a good dig, the kind that, if you work for a big company, they're not always comfortable with you addressing. So it needs to be addressed, because you have to work all the harder at a large company with significant inertia to change behaviors.

Every year or, more accurately, twice a year, we do reviews at my corporation. I've had direct reports on and off for several years now, which necessitates doing reviews, and I've always been asked to do plenty of non-direct report reviews because I have a reputation for putting some thought into them. Fortunately, I'm running a little lower than my heyday of twenty plus, but with a bevy of direct reports (up 700%), I'm sure to have more this year. What I try to get into a review is not just my impressions from the year, but a reevaluation of my own impressions, trying to ensure a.) I haven't told myself a story about someone that's coloring my perception. I try to give everyone a clean slate in the sense that I throw away the narrative I tell myself about them and let them recast their narrative for the next year. Part of each review is identifying the story that was built up over the year and what was concrete and what was interpolation. In some respects, I try to build a counter story for the next year, so they have to work at dispelling a positive impression I've put together, actively working to dissuade me of their innate need to succeed. And b.) that I haven't internalized someone else's story for the same reason. I find that to be even more important, as stories about employees are rife in a company with 5000+ individuals at a site, and they tend to stick for longer than you'd suspect. One of the most important things in working toward being a manager was to identify the stories being bandied about in regards to me and actively work to offset the negative ones. If you haven't picked up enough of my personality in previous blog posts, the bigs ones were 1.) not promoting myself enough because I wasn't interested in getting ahead (make noise, even if you're not interested in a job or an opportunity, you have to explain your perception of why it's not the right move), 2.) not being an advocate of "up or out" (I'm still not, but it's mandatory I have a story to explain my own version of up or out and how it fits into the corporate strategy), 3.) not looking like I feel entitled to promotion (this fits in with, I know better how to manage my career than those who are trying to manage it for me...it's an incredibly fine line, and there was a lot of misperception initially, much of it my own doing - see #1).

That would seem to be a post in its own right. But it's just the opening.

This year, I heard one of these stories being shopped around. A recursive review story if you like, because the story is "X is an easy rater." I'm instantly suspicious whenever I hear the same story coming from multiple managers, unless I've been the one to put the story out there in the first place. If someone is regurgitating my story, I see it as an opportunity to refine my message. If it's a story I'm unfamiliar with, I suspect someone else of pushing an agenda. To the best of my knowledge, there's no fact or statistics behind this particular story. It's just being adopted as gospel because it's convenient. I've argued the flip side in manager meetings with a variety of "tools", as my last manager referred to that set of skills. A bit of displacement: our rating system seems to be tougher overall this year. Manager A used to rate most of his team particularly high. If he had still been here, we'd have been 10% higher overall. We're lower than we should have expected. This leads to discussion and some humor, with full knowledge that it was statistically accurate that up to 60% of Manager A's team(s) used to get in the top 20-30% of ratings.

Wait a while, then add the confusion tool when meeting with other leads and managers, using it to extend the narrative and reinforce it beyond the initial review meeting. "But perhaps Manager A used to rate his team(s) so high because they were together so much and really brought each other up as a team." The inevitable follows, "But we still need to evaluate the individual against the whole. Is Q1 really more qualified than Q2? Did they produce the same amount of work? Did they make the most of their individual opportunities? Why are they where they're at after all this time?"

It's at that point that I drag in the whole ethos of the department, "Didn't we change our organization so that we'd take the focus off the individual and put it on the team? Isn't our new direction centered on verticals and Agile? Shouldn't we be rewarding teams that exemplify what we're organizing toward?"

Loop it back to the initial discussion. The initial story. "That reminds me of X's team. They were criticized earlier in the year for their lack of ownership Not as individuals, but as a team."

There's a bit of dissembling from the whomever I'm talking to, which I'm counting on. I immediately move to offset with, "It was my director who called them on it. We had a lot of discussions around ownership and that team and how to remedy the problem. I was in the followup and review meetings to discuss what was done well and what was not. Individuals were mentioned, but the concern was with the whole team and how to change the communal attitude."

I'm not saying Director R would be easy on ratings. I know better. But Director R would be looking at whether ownership improved with that team this year and how that was servicing the wider department. That improvement might be credited to the lead. But the team improvement would be the crux of any investigation. Director R wouldn't be as concerned with the ratings. They were secondary to Director R's goal of better teams, better ownership, and better communication. So I ask myself, is their ownership better? Is their team better?And the answer is, almost to a person. They've changed one of their internal stories and followed through on living it at work. It's almost too bad we carved them up with the reorg, as they seem indicative of what we're trying to capture going forward. Ownership. Team focus. Reinforcing each other. Living or dying as a team. There are exceptions. But our own rating system works against really calling out the poorest players, pushing everyone toward a central bell that is more than a standard deviation wide on each side. 75-80+% fall into the middle. Reviews don't recognize the individual. And they don't recognize the team. If our reorg was truly focused on Agile, it should strengthen, should reinforce, those internal connections that are hinted at by teams with elevated ratings, that indicate Agile teams where there's a desire not to let down your coworkers, even if the individual review process weakens what we're trying to create.

Can you mentally scrap our review system? Instead, picture what teams you would reward for working well together, despite the restrictions and roadblocks that are there, that we're attempting to eliminate. Are they the same teams the highest rated individuals are on this year, or are there teams that produced without star players? Maybe X's team, even if you don't know them well enough, falls into that paradigm. Maybe X believes that of them.

And here we get to a big slice of the issue. Malcolm Gladwell says in Blink that we adjust to our explanations. We adjust to our stories. And if our stories are about rating the individual, and not rating the team, then that's where we put our focus. And the biggest issue is that our vocabulary, how we cast and perceive how we talk about something, is limited to a shared vision. In this case, the individual, not the team. Gladwell talks about "jam idiots". People who know that something is wrong, but can't talk about it, because they don't have the vocabulary to explain why it is wrong. In the case of reviewing jam, you don't know to talk about taste, texture, berriness. In the case of reviews, you don't know that "team" is a possible category. Experts have a vocabulary. If your'e not an Agile expert, team is not necessarily an intrinsic part of your vocabulary.

We file patents as a team. We produce as a team. We work as teams. We review as individuals. If our goal, our drive, is to create high-quality teams of craftspeople who work well together, then the vocabulary has to change. The review process has to change. And the courage to address that process has to change. It can't be something that even higher level leaders are afraid to address in print. There has to be a better way. And there has to be a better story. About the team. Not about the individual.

What do Agile Managers Look Like?

What does an Agile manager look like? According to Alan Cooper at Code Freeze, you can't manage craftspeople. Instead, you have to facilitate. A good Agile manager will:

• Define and reiterate the overarching goal (focus on the quality line, not the deadline),
• promote standards,
• focus on what to avoid and potential obstacles,
• help everyone on the project focus,
• own the problems and eliminate roadblocks. [author's note: as a manager, I consider this to be paramount. Making sure developers can come to work, sit down, and start coding, is priority number one for a good manager, whether they be Agile, or traditional waterfall].

The factory has moved to the brain, and managers who continue to follow an outdated factory floor management paradigm are going to have an issue with that change. Don't think you can convince them. Just do the right thing and drag them along so they have to confront reality.

Sanjiv Augustine in "Managing Agile Projects" repeats this same criticism, "Managers trained in predictive, plan-driven project management techniques face a learning curve when entrusted with the management of agile development projects." (xvii)

What do Agile Managers Look Like?

Alan Cooper was asked at Code Freeze 2010 "What do Agile Managers Look Like?" His response was, a manager can't manage craftspeople. Instead, they have to facilitate. A good Agile manager will [and I'd posit any manager should]:

1. Define and reiterate the overarcing goal (focus on the quality line, not the deadline),
2. Promote standards,
3. Focus on what to avoid and potential obstacles,
4. Help everyone on the project focus,
5. Own the problems and eliminate the roadblocks.

The factory has moved to the brain, and managers who continue to follow an outdated factory floor management paradigm are going to have an issue with that change. Don't think you can convince those managers. Just do the right thing and drag them along so they have to confront reality.

Dirt

Eryn and I spent yesterday after work moving dirt at the duplex. Ah...it seems like only yesterday that I was moving the leftover clay from the front yard to the weeded area in the dog pen to cover up the waist high weeds. And now I'm moving it from the area that won't even grow a weed to the open-sided shed in the back so that I can plant grass for the new tenants. I wonder when I'll have to move it from the open-sided shed to somewhere else?

Actually, in this picture you can see a weed or two, but they weren't faring well. The roots from all those trees, on the other hand, were doing fabulous! Every shovelful was an exercise in wood cutting.


I tried to get Eryn to measure her scoops and beat herself with each wheelbarrow, and then explained that was part of managing people. Then I challenged her to a most scoops contest and explained that I was able to claim 10-20% of each of her scoops as it was my project. I'm hoping this convinces her to be her own boss when she's older.