Software Engineering, Project Management, and Effectiveness
How to be a leader in your field? Dragos shared a link to How to Be a Leader, which I found interesting. In the article, Philip E. Agre presents a six step recipe for becoming a leader in your field:
I think the takeaway was that to be a leader in the field, you help move the ball forward. In step 1, Philip gives an A-Z list of how to pick which ball to move forward.
Another part of the article caught my attention. Philip writes:
"To succeed in your career, you need more than the skills that you got in school -- you need to be the world expert in something. Knowledge is global, it's growing exponentially, and nobody can pack all of the necessary knowledge into their head. So everyone's going to specialize."
I think there's a lot to be said for focus and specialization. The trick is picking what to specialize in. Personally, I like to specialize in skills that compound over time versus flavor of the day.
It's obvious in retrospect, but I found a distinction between low-friction communication and high-friction communication. By low-friction, I mean *person A* doesn't have to work that hard for *person B* to get a point.
I find low friction scenarios are often cases where *person B* starts with the mind-set "how might that be true" and they help *person A* tease out, or make their point. The starting point is collaboration -- two people working to understand the message. I find high-friction scenarios are often cases where *person B* starts with the mind-set "let me tell you how you're wrong."
It's really easy among a bunch of engineers to rip ideas apart. The trick I found is to first ask, "how might that be true?" This gets over the potential hump that maybe while the delivery was off, there was merit in the message (or a concept needs help to be teased out) and it certainly builds more rapport than starting off as a devil's advocate.
How do you get past deadlocks in a meeting? You can apply the Six Thinking Hats. I've blogged about the Six Thinking Hats before, but to summarize, it's a way to get everybody thinking about the problem in a collaborative way.
The Keys to The Six Thinking HatsThe real key here is that rather than circular or deadlock debates, you focus the group on a particular viewpoint at a time. This is a similar to writing, then editing vs. editing while your write, or brainstorming, then critiquing vs. critiquing while you brainstorm. The big difference is that rather than just brainstorming and critiquing, you're looking at the issue from multiple, specific angles. On the people side of this technique, you're letting people wear a different "hat", in a safe, constructive way.
Applying the Six Thinking Hats The approach below is lightweight and low-overhead, but gets you 80% there without requiring everybody to know the details of the Six Thinking Hats.
Summary of Steps
Step 1. List the questions that represent the hatsList a set of questions on the whiteboard to represent the hats. You can do this either at the start of the meeting or when you hit a sticking spot.Here's the Six Thinking Hats:
Here's an example set of questions you can use to represent the hats:
The sequence of the questions can matter. For example, it wouldn't make sense to start thinking up solutions before you've focused on the problem.
Step 2. Walkthrough each question as a teamWalkthrough each question as a team. This is the key. Rather than debating each other, you're now collaborating. You'll be surprised when suddenly your team's "Devil's Advocate" is now showing off their ability to dream up wild solutions that just might work!
Step 3. Modify the approach.If it's not working, change the approach. For example, you might find that you started with the wrong "hat" or question. See if switching to another question or hat makes a difference. The key is to keep this lightweight but effective.
This isn't a heavy handed approach. Instead, it's a subtle shift in stratey from free-for all debate to focusing and coordinating your team's thinking power in a deliberate way. This lets everybody get heard as well as really bang on a problem from multiple angles in a teamwork soft of way.
Well, it's official ... Software security is in for a ride! -- Mark Curphey joins Microsoft. Mark already brings a ton to the table in terms of ideas, network, and results. At Micrsoft, he'll crank it up. Congrats Mark and I look forward to our future adventures!
Our Scenario Frames for Team Foundation Server are available on CodePlex. We have Scenario Frames for the following:
We use scenario frames for several things:
The real power of a scenario frame is that's it's a shared frame of reference. Personally, because I've seen so much benefit from scenario frames time and again, I couldn't imagine doing guidance or building a product without using scenario frames.
My Related Posts