My company recently held HR training for managers where the instructor said:

• Do not require dates of employment on applications
• Do not note or refer to dates on someone’s resume or application

All this because considering age when hiring is, in most cases, both wrong and illegal.

• If I list three jobs, each of which I worked four years, am I over 40?
• Same jobs with dates. I began the first job in 1992, am I over 40?

I thought I’d ask LinkedIn why they require the display of dates.

This is their reply…

From: LinkedIn Customer Service
Sent: Monday, August 13, 2007
To: Ken H. Judy
Subject: Re: dates worked in experience profile

Hi Ken,

While we can understand your position along with your companies HR training basically providing the length of employment or the dates you began with a company (start date) and the date you left the company (end date) would pretty much be the same. If I started with LinkedIn March 01, 2007 and I left them April 1, 2007 that would mean I was one month old? I don’t believe this would really have much to do with a person’s age. When entering employment dates on a resume you don’t enter your date of birth neither should you do that on your CV. Please let me know if this addresses your concern as I am not sure I understand how entering your employment dates is age based discrimination.

Thanks

I’m comforted that you “understand my position”. Thanks LinkedIn Privacy Lead!

I realize experts recommend listing dates and only using the most recent 10-15 years of experience. Still, what I reveal about myself is fundamentally my decision not the administrators of a social network.

Oh, and thanks for clearing up that thing about the one month olds. I was confused about that one…

Posted: August 31st, 2007 under Uncategorized.
Comments: 1

Handoff
Creative problem solving as rote mechanical construction. Twist the wrench and pass it on.

• forces sequential phases, “first we determine what it looks like then we figure out what it does.”
• forces development in horizontal rather than vertical layers, i.e. “we’ve spent weeks coding but none of it does anything yet. We’re almost done though”
• forces thinking in schedules instead of priorities, “I’ll have my part done in two weeks. What is it again?”
• silos workers from each other, “What are you working on? Well, anyway, goodnight.”
• ensures workers don’t have big picture, “Her copy doesn’t fit in my div based on his mockup. It’s not my fault.”
• encourages hierarchies and coordination overhead (chicken husbandry), “My manager will get with your manager”
• enourages narrow specialties instead of versatility and craftsmanship, “He does jpegs and gifs. She does html, css, and javascript. She does C# and Java. None of us actually build applications. By the way, did I already say it’s not my fault.”

Approval

Distill complex interactions into a pretty picture. Take authoritative guidance from someone who’s only spent 15 minutes thinking about the problem.
• encourages passive, diffuse product ownership, “you’re on the hook but they’re the deciders”
• locks in premature commitments, “I put aside $10K for database integration”
• invites arbitrary changes. “make this bit here blue”
• creates low-value artifacts that lie, “sure it will work just like the wireframe.”
• rewards promises over performance, “it will do everything I say, cost $40K, and be done in one month.”
• bakes failure in, “how did we end up with this late, expensive hunk of junk?”

Getwith

offensive getwith: “you need to getwith Joe on this.”
• forces input from people with authority, no accountability and no direct contribution — like being made to run around with a target on your back

defensive getwith: “Does Joe agree with this decision?” “I gotwith him on it.”
• ask someone to attend one meeting, characterize them as agreeing with anything you do after that — like pulling a target of your back and sticking it on someone else’s

Any additions?

Posted: August 29th, 2007 under Uncategorized.
Comments: none

ACM Technews referenced this article from searchcio.com.au.

IT still trying to find what women want

The world is flat. Better go out and hire some women.

That seems to be the gist of a recent Gartner report on the gender gap in information technology …

The article lists five gender-based traits CIOs should pay attention to when building IT staffs.

There’s a danger of drawing conclusions about individuals from differences in large samples. Just because men are statistically greater risk takers than women doesn’t mean I’m bolder than any particular woman. Or that she has better listening skills.

But at the level of an entire industry statistical differences are meaningful. Software would be better if we had collaborated and communicated better. Our products would be better if we had more empathy for customers and end users. Attracting qualified women into the field is a contribution to that end.

As the article suggests, the only appropriate way to do that in the context of a specific hiring decision is to include people skills as a requirement of the position, cast a wide net and hire the best candidate.

But you need to have a workplace and compensation package that is attractive to someone with people skills, technical chops and wants to give you their best at a sustainable pace.

To the argument that inviting women into a dysfunctional IT culture won’t make things better, I’d say that’s not my point. More women in IT is a hoped for result of humane workplaces — not a solution for creating them.

We have to work from within to make our companies better. In my software development team, our use of Scrum and XP has helped us do that. So far, my employer has been receptive.

I know that isn’t true everywhere. All I can say is those of us who have a choice sometimes have to make tough decisions about where we choose to collect our paycheck.

Posted: August 29th, 2007 under Uncategorized.
Comments: none

As a technical manager, what am I for? What are my core values?

Nurture a passionate, focused, autonomous team. Attract, retain and develop people who do right for their team.

Approach the manager’s work with humility. It’s not about getting people to do what I want. It’s about having a team that owns what they do and does it well.

Wed developers’ desire to contribute and love of problem solving with practices that minimize waste, reward learning and provide continual contact with customers.

Hold the team accountable for their commitments. Have them define their own standards of performance (estimates, quality practices, definition of done). Allow them to feel the inevitable disappointments. Celebrate their achievements. Always expect them capable of improvement. Treat their collective workspace, opinions, and time with utter respect.

Always seek out the next challenge and deliver on commitments.

Don’t wait for ways to provide value to my employer. Anticipate the next change or growth. If wrong, react to it.

Avoid make work. The goal isn’t to keep the team busy. It’s to keep them contributing.

Teach senior management the value of the team by what they do. Project success drives organizational change. It trumps reasoned debate. Project success can sometimes even win out over habit, emotional ties, and political ingenuity.

Treat all people ethically

Authority is a trust assigned to me for a purpose. A leader’s behavior shores up the workplace behavior of others and affects the health, happiness and family life of staff. Be accountable to that.

If there is a purpose in work and in life it is not to create unnecessary human suffering.

Posted: August 11th, 2007 under Uncategorized.
Comments: 1

Last year (2006), my boss Steve Morgan gave me this MBO:

Don’t become like the pointy hair guy and help the Execs to not become like the pointy hair guy

Is there an incremental path to becoming “The Boss”?

Posted: August 3rd, 2007 under Uncategorized.
Comments: none

I have managed Oxygen’s Software Development Team for five years.

Each year, our aspirations grow to encompass widening arcs of project, team, and company.

It all seems planned but it’s a pattern of intended and emergent strategies. Agility embraced from the bottom up with the support of our CTO, Steve Morgan.

Beautiful.

Posted: July 2nd, 2007 under Uncategorized.
Comments: none

I want to collect together all the terms that describe activities at the start of software projects.

The fuzzy front end

• Discovery
• Ideation
• Brainstorming
• Chartering
• Initiation
• Information Architecture
• Wire Frames
• High-level Design
• High-level Requirements

Big design up front

• Mocks
• Conceptual Modeling
• Specification
• Detailed Design
• Detailed Requirements
• Software System Architecture

Any additions? Please…

Posted: July 1st, 2007 under Uncategorized.
Comments: 3

I’m on the management side of the labor divide and yet I’ve never held a position my parents would consider a permanent job. To work these days is effectively to be employed at will.

I once had a senior executive tell me that my team was an experiment. To prove the value of development staff, we had to replace an outsource, maintain their legacy applications, and deliver a challenging new project. If we failed, next year’s budget would go to re-establishing the outsource.

We faced a hard date, skeptical clients and a steep learning curve but we had an honest leader, the means to succeed and a way of measuring it. All we had to do was execute.

I never felt more control over my fate.

A family friend works for Doctors Without Borders. His labor benefits society in ways that will outlive him. In the balancing act that is my life — privileged by world if not New York standards — I’ve deferred, if not entirely foregone legacy. My job is about significance and achievement. Significance comes in providing for my family, not only a biological imperative but a profound joy.

Achievement rests in approaching each year as if it were an experiment. What accomplishment justifies my continued employment? What one thing should I do to materially advance the interests of my employer, our customers and/or my team? It’s the chart of that course that makes me show up in the morning and it’s sightings along the way that allow me to sleep at night.

Posted: March 17th, 2007 under Uncategorized.
Comments: none

Dave Pollard has an interesting post, From Simplistic Thinking to Embracing Complexity.

On attempts at knowledge creation that don’t engage employees and customers…

such systems presume ‘learned helplessness’ of customers and employees: The customer, the citizen, is often viewed as a mere, passive consumer of your organization’s products and so-called wisdom. The employee, likewise, is assumed to be ignorant, stupid and disinterested in the success of the organization beyond his/her own job. Most people don’t take kindly to having their intelligence insulted. And failure to engage customers and employees in co-producing the product is a tragic waste of great opportunity.

Learned helplessness. Yup, that about sums up what it’s like to work for a product owner who refuses to let the team invest in the vision of a product. Complexity and invention don’t lend themselves to command and control.

There are individuals like Dean Kamen with a singular genius for invention. Still he emphasizes the value of collaboration – of sensitivity to others and society. His F.I.R.S.T. foundation celebrates the whole individual engaged with others in a technical challenge and the ethic of Gracious Professionalism.

It’s a way of doing things that encourages high-quality work, emphasizes the value of others, and respects individuals and the community.

Agile software development values collective ownership. However, there is shared code and there is shared risk and shared reward. When a FIRST LEGO League Team wins, I’m sure it’s not a single 14 year old product owner who accepts the prize.

For a development team to contribute beyond the bounds of technical execution, i.e. “his/her own job”, product owners need to approach them

…through conversations, stories, and presenting the ‘problem’ to them so they can help you appreciate it better and then address it. – Dave Pollard

Embracing complexity is about engaging the whole person not just the coder. With the person comes life experience, passion, and imagination. As product owner, use your authority to break through indecision but avoid the desire to tell the team how to solve your problems. Describe what you are trying to accomplish and why it is important. Get the team in touch with the customer and let them help you.

The result will be more than the formulation of a single mind. It will be more what the customer needs and, perhaps, it will be unlike anything else out there.

Posted: March 10th, 2007 under scrum.
Comments: none

My team is currently working on two very different programs by pulling work off both backlogs into a single sprint. We did this for pragmatic reasons having to do with our size and the wishes of both the product owners and the team. This was working well when the two programs were clearly defined projects. However, we’re going through a rough patch with one program driving maintenance work and the other rallying towards release. We’re paying a price for context switching with lower point commitments overall per sprint.

Inspect and adapt.

The Washington Post published an article by Lori Aratani, Teens Can Multitask, But What Are Costs?

When subjects were focused on sorting, the hippocampus — the part of the brain responsible for storing and recalling information — was engaged. But when they were multitasking, that part of the brain was quiet and the part of the brain used to master repetitive skills — the striatum — was active.

The Journal of Experimental Psychology published a paper by Joshua S. Rubinstein, David E. Meyer, and Jeffrey E. Evans on Executive Control of Cognitive Processes in Task Switching. As an APA release summarizes:

…subjects lost time when they had to switch from one task to another, and time costs increased with the complexity of the tasks, so it took significantly longer to switch between more complex tasks. Time costs also were greater when subjects switched to tasks that were relatively unfamiliar.

Neither the article or paper distinguish results by gender. The First Sex says that according to gender specific studies women are better multi-taskers than men.

I bring up the gender differences because I work at a women-owned company. One of the benefits is seeing the world from my CEO’s point of view. Sometimes not identifying differences between men and women denies women opportunities, or worse, perpetuates harmful stereotypes. As a society, we are late to acknowledge that women present with heart disease differently than men. This has perpetuated a myth that heart disease is a male illness.

“(A)ccording to the American Heart Association (AHA), more women than men die from heart disease in the U.S., and 1 in 3 women is living with it today” – TIME Magazine

If women are truly better multitaskers, maybe they have some inherent advantages in certain kinds of jobs (like mine ).

Both the men and women developers in my team have acknowledged that the context switching penalty has gotten worse recently. So whatever the difference in this case, some kind of scrum master response is required.

Posted: March 3rd, 2007 under scrum.
Comments: none