I, Engineer » Leading projects

Clever Hans

lubkin — Tue, 23 Dec 2014 17:58:36 +0000

Physicist John Killeen was director of the National Magnetic Fusion Energy Computer Center (NMFECC) at Lawrence Livermore National Laboratory, but deputy director Hans Bruijnes was our day-to-day boss.

The morning would almost always start with a Hans-led all-hands meeting. It usually felt like a waste of time. But he believed in it. We should come together every day as a team, and all know what everyone was working on and what the key issues were.

Hans was a great practitioner of management by walking around, long before it became popular. He’d randomly stop by your office, ask what you were up to. Occasionally confusing matters by telling you to do X when your group leader had told you to do Y. Eminently mockable, but always with affection and respect.

I wish I’d known all the backstory in his obit when I’d see him every day. Find a long lunch at the Concannon winery to hear his version.

A good man, who will be missed by anyone who knew him.

Flying in close formation

lubkin — Fri, 19 Dec 2014 15:16:53 +0000

When you’re over Mount Rainier, you want your pilot flying an airplane, not 100,000 parts in close formation.

Companies don’t ship software. They ship products. (Or deliver services. Same thing.)

A product has (at least) code, test code, graphics, documentation, training, customer support, marketing, sales, advertising, technical marketing, HR, maintenance, legal, accounting, other products it needs to work with, and a bevy of external partners—alpha and beta participants, investors, administrators, recruiters, third-party developers, book authors, industry writers, competitive partners, customers, and end-users.

And you succeed if the entire product succeeds. Not just your corner of it.

As a project lead, you will most often meet with your peers and direct reports. But you need to know and have a good working relationship with people in each of the roles in the extended team. Your work feeds into theirs and vice versa.

Be sure they have a say in what will be committed to when. And that they feel they have.

Ask how your development team’s ideas impact them. That easy whizbang you want to add at the last minute may be an afternoon’s work for one of your software engineers. But it’s an eng-month for an affected group.

Be open to ideas from any one of them. They may not use the correct terms. What they suggest may reflect a misunderstanding. It’s still worth your time and part of the job.

If you’re not lead, this should matter to you too. If you don’t want the endeavor to be successful, why are you working on it?

Writing bad checks

lubkin — Mon, 15 Dec 2014 21:52:38 +0000

Don’t write checks on someone else’s account.

One of the quickest ways to damage a relationship is to commit someone else to a task or a deadline without discussing it with them first. Whether it’s promising your spouse will chaperone a field trip, the assault team can rescue the hostages, or the spacecraft is go for launch.

Don’t commit to yes. You need to discuss it with the team. Do commit to that and to when you’ll be back with an answer.

It may ultimately be your decision. But everyone appreciates being consulted and resents being ordered. Be a leader, not a boss. Plus there might be a fundamental reason why what was asked for simply can’t be done, period. That they’d tell you if you ask.

Of course, you also need to be someone they feel safe to tell the truth to, and want to.