7 Top Traits of Star Employers

Posted by Robert Merrill on August 25, 2014 under Office Relationships and Politics, Software teams | Be the First to Comment

I just read 7 Top Traits of Star Employees on inc.com.

They are:

  • Happiness
  • Creativity
  • Hustle
  • Honesty
  • Flexibility
  • Passion
  • Confidence

Hard to argue with these. But which is more important, that a candidate have them on interview day (assuming you can tell), or that an employee have them after a year working for you?

Every senior leader has beliefs about nature vs. nurture. If it’s nature, star employers hire stars. If it’s nurture, star employers develop them.

The author of the inc.com article writes as though it is more nature than nurture. Is Mr. Hendricks right?

Here’s a straightforward assignment for your HR people.

  1. Evaluate candidates for these traits.
  2. Evaluate employees for these traits after a month.
  3. Evaluate remaining employees for these traits after a year.

Here’s how to interpret the results:

No change or increase in first month Decrease in first month
No change from first month to first year You win!. It’s nature, and you’re good at hiring! You lose. It’s nature, and you’re seeing the traits when they’re not there.
Increase from first month to first year You win!. It’s nurture, and you’re developing (or rescuing) stars!
Decrease from first month to first year You lose. It’s nurture, and you’re dousing stars, even if you were hiring them to begin with.

Another Load-Bearing Wall of the House of Agile?

Posted by Robert Merrill on May 21, 2013 under Agile Methods, Peer Leadership, Software teams | Be the First to Comment

Agile has reached the early majority, and is running into trouble. At best, it doesn’t deliver what it’s capable of when the shackles are off. At worst, its failure feeds the political beast and vaccinates the organization against future change. “We tried that Agile nonsense, and it didn’t work! I Told You So™!”

Usually, Agile fails because organizations leave out an essential feedback loop.

  1. A governance process sets scope, schedule, and budget before initiating the Agile project, disabling the feedback of observed productivity (velocity) into a variable scope (the prioritized backlog); the team devolves to Cowboy Coding under the schedule pressure, and the product remains locked into a definition created when everyone was the most ignorant they will ever be,
  2. The team doesn’t do automated testing because they don’t know how or aren’t given time, disabling the feedback loop that controls technical debt; refactoring—as-needed redesign—is too risky, and productivity drops because the design is becoming incoherent,
  3. A defined process, outside the control of the Agile team, inhibits meaningful change based on retrospectives, which become glorified lessons-observed post-mortems instead of the lessons-applied process feedback loop they were meant to be, or
  4. Functional boundaries inhibit the frequent, regular evaluation of finished software by production SMEs and stakeholders in production-like environments, disabling the right-thing-done-right feedback loop.

Since early 2009 (four years at this writing), I’ve been using the metaphor of a house’s load-bearing walls to explain this. You can remodel Agile to suit your environment, but you can’t cut through a load-bearing wall, or it will fall down. In a match between personal will or political “realities” against the laws of physics, the smart money’s on the laws of physics, every time.

But I just read an article called Your HR Department can be hurting your company that caused me to say, “Maybe I’ve been missing a wall!” It’s not the gist of his article, but Don Herrmann makes this fascinating statement:

The real focus should be on leadership and for that a leadership expert is better suited.  Notice I said leadership, a method of self directed empowerment that has sustainable accountability.  I did not say leader, an others directed process relying on personal style that is not sustainable.  Focusing on leadership ensures the long term strategic direction of the company is properly defined, navigated and accomplished.  It survives the natural departure of leaders by ensuring a replicable and consistent conductor culture for the company.

This lack of what I’ll try calling “Peer Leadership” in established organizations explains some things I’ve experienced.

I frequently use Facilitated Requirements Workshops to elicit and analyze software requirements. The tensest moment for me is what I call “marker allergy.” I’ve just asked them to start writing user stories on 4×6 cards, using the markers in the middle of the table, and they’re just sitting there. And I’m wondering, “Are they allergic to markers or something?” They’ve always started writing, eventually, but meanwhile you could cut the tension in the room with a knife.

Or, we’ve just come out of a cycle start meeting with the sponsor/product owner with a set of user stories we’ve committed to, and we need to organize the work. They’re usually OK with putting together a WBS (Work Breakdown Structure), but when it comes to “Who Does What by When,” they all look at me. I’m the expert. I’m the “leader.” So I’m supposed to issue orders, and go down with the ship if need be, and I’m instead impersonating a mime. Eventually they get over it, but meanwhile you could cut the tension in the room with a knife.

Agile proponents talk a lot about self-organizing teams. I’ve spent all of my programming life in cultures like academic research and then start-up businesses where this was a given. The people were there in part because they couldn’t stand being told what to do! So I never really thought about self-organizing teams because that’s all I knew, until I started consulting in organizations with a management culture, and a “but I followed instructions” response when things go awry. It’s not their fault. It’s what they’ve been conditioned to do. They expect it, and there’s safety in it. Like Wallace, I can tell the sheep to “get yourselves organized down there,” but the results (after about 1:30 in the video) might not be as spectacular.

Perhaps Self-Organization or Peer Leadership is a fifth load-bearing wall, but one that needs to be installed, not merely protected like the others. Maybe team members used to big-M Management need explicit help with Peer Leadership. As a first draft, I’d include training and then coaching on how to:

  1. Size up and divide work,
  2. Estimate work, and help others do the same,
  3. Suggest first-draft ideas without being afraid of being wrong (or “getting a bad grade”–there’s a lot of PTSD left over from school. Just ask about the dreams),
  4. Be mindful of the “vibe” of the team and the work they’re producing,
  5. Identify strengths and weaknesses in self, others, and team, and change your mind when the evidence suggests (tell Malcolm Gladwell of Blink to go to blazes),
  6. Give feedback without becoming snarky, and
  7. Receive feedback (even snarky feedback) without becoming defensive, or, as Alan Godwin puts it, how to have Good Conflict, and
  8. How to prepare and give a simple briefing to a project sponsor without freaking out.

I’d then prep the sponsor on how to respond when things go awry (and they will). Keep the “Who’s in charge here?“ inside, and instead say, “What do you all plan to do differently now?” The experienced sponsor should use that experience to ask questions that help the team strengthen their plan, and resist the urge to pull an Al “I’m in charge here” Haig.

When people start to learn that they can’t hide behind a manager, but that they can take responsibility for their successes and failures, choose how to respond to the latter, and not get shamed and whacked by those with Authority, I’ll know that Peer Leadership is taking hold, and that our load-bearing walls are complete:

  1. Frequent inspection of running software in a (near-)production environment, by production people (functionality and usability feedback),
  2. Commitments based on actual velocity (productivity feedback),
  3. Automated testing (quality feedback),
  4. Regular retrospectives, resulting in action (process feedback), and, welcome to our new load-bearing wall,
  5. Peer leadership (team cohesion feedback).

Let’s try it out. Let me know how it goes!

Thoughts on “Not So Fast…10 Steps to Take Before Hiring a Web Developer”

Posted by Robert Merrill on December 17, 2012 under Project Set-Up, Software teams | Be the First to Comment

In the Society for Professional Marketing Services (SMPS) Wisconsin Chapter newsletter, Melissa Opad writes, “Picking a web developer is like picking a spouse…While that’s not exactly true (at all), it is a very important decision that will have great implications on the success of your website project.” Ms. Opad then goes on to list 10 Steps to Take Before Hiring a Web Developer.

Ms. Opad has a lot of good advice, but there are also a few things that I think are a lot more like choosing a spouse than writing a tight Hollywood-style pre-nup.

Based on my experience as a web application (primarily eCommerce) developer, web/software project definer and estimator, and consultant to firms hiring outside help for their web and software projects, here’s my take on Ms. Opad’s 10 steps: Read more of this article »

I Might Even Annoy You

Posted by Robert Merrill on September 16, 2012 under 100 Words, Change Leadership, Software teams, uFunctional Values | Be the First to Comment

One of my first posts was Who I am Not.

So, “You annoy me—You’re Hired!” on StaffingTalk.com immediately caught my eye.

The premise is that you should hire people who aren’t like you, even to the point of rubbing you the wrong way, if you want to build great teams. (I would add that they must still be trustworthy, competent, of good character, and otherwise worthy of respect). Now, getting that team to jell—getting through the Storming stage of Forming, Norming, Storming, and Performing—might take longer and be more challenging, but the results will be worth it. And if the team’s mission is a worthy one, jell they will. And when they do, they will totally kick.

So, if you have a software-related mess, or better yet, you don’t want another software-related mess, listen to Uncle Albert (who was in fact just about the sharpest knife in the drawer):

We can’t solve problems by using the same kind of thinking we used when we created them.

I promise I’ll try not to annoy you. But helping you straighten out your software problems, and prevent them recurring, will my top priorities.

I hope this helps you make better decisions for your organization, whether they involve me or not.

And I think I just gained some additional insight into my sales problem.

Forced March, not Death March

Posted by Robert Merrill on January 17, 2012 under Software Development, Software teams | Be the First to Comment

For almost exactly two months, from mid-November 2011 through mid-January 2012, I was on a Forced March, meaning lots of overtime and weekend work to get a software system up and running. It’s still not live—the sponsor switched from Date-Driven to Done-Driven and slipped the launch date six weeks, but not after I’d worked pretty hard.

These are sometimes called Death Marches, after Edward Yourdon’s book, in turn named after (I guess) the Bataan Death March. This was nowhere close. First, comparing anything that’s ever happened on a software project to the likes of Bataan shows a terrible lack of perspective. Second, even as software projects go, this was short and not at all harmful for someone in my circumstances of life. Third, “death march” implies at best a selfish motive, at worst a truly sinister one, and most likely just macho stupidity (read about Electronic Arts and judge for yourself). Read more of this article »

Lessons from a Forced March

Posted by Robert Merrill on December 26, 2011 under Software Development, Software teams | Read the First Comment

My primary client is going live in one week (1/2/2012) on an Order Management System that’s been in the works since March 2011 and was selected in August. For me, it turned into a forced march in mid-November—six-day weeks, extra hours, and more stress all around that I would have liked.

It’s part of my professional mission to prevent such things, and I ended up with one anyway. The tuition’s largely paid, so lets at least make sure we get something out of the course.

  • What was the primary cause?
  • What were the contributing factors?
  • What have been the consequences?
  • Could it have been prevented?
  • What can I, and you, learn from it?

Stay metaphorically tuned for a series of blog posts, but not for another week or more. One of the direct consequences was no blogging and very little other marketing activity for uFunctional LLC. The long-term consequences of an empty pipeline are about to become apparent.

Why Big Projects Often Have Problems

Posted by Robert Merrill on April 6, 2011 under Software teams | Be the First to Comment

This popped into my head the other day, and stuck. I need to examine this carefully. Does it really hold up, at least in my experience and that of others? If so, can something useful come out of this idea? So, expect this post to change. I’m thinking out loud a bit.

Big projects cost lots of money.

The presence of lots of money attracts people who love money.

The love of money is the root of all sorts of evil.

Evil causes problems.

I can’t recall reading a software development or management book that didn’t assume that people are trying to Do The Right Thing, and that the problems project teams get into were the result of increased complexity or ineffective ways of working together.

But if I’m trying to help clients’ projects and businesses succeed, and I’m overlooking a critical factor, I need to consider it, even if it is impolitic to do so. As a consultant, that’s sometimes my job—to say what every insider knows but is afraid to say. If I get fired, I’m only losing 1/4 or 1/2 of my job, not the whole thing, so I’m expected to take chances.

It’s generally agreed that big projects are more likely to have problems. But what about this notion of big money, and evil? Let’s look at it, one line at a time, and see if there’s anything useful.

Return often. This is a work in progress. I’m thinking out loud, and I welcome your (useful) participation. Read more of this article »

The more important the project, the less effective the team

Posted by Robert Merrill on September 21, 2009 under Software teams, Software-Intensive Businesses | Be the First to Comment

Think that your software team performs best under pressure?

Not if what a Harvard Business School professor learned about other knowledge workers—auditors and consultants—applies to programmers, too.

In Feeling the Heat: The Effects of Performance Pressure on Teams’ Knowledge Use and Performance, Heidi Gardner explains that the pressure triggers “threat rigidity,” and causes “reduced cognitive processing.” Teams under pressure are also more likely to defer to “high-status” team members, rather than make full use of those with the most relevant, specific expertise.

Prof. Gardner’s research involved 72 teams of management consultants and auditors across twenty regional offices of a Big Four firm.

Leading a software-intensive business means overseeing some high-stakes projects–there’s no way around it. But don’t assume that the people doing the work will respond to the pressure the way you do.