Archive Page 3

14
Mar

Product Ownership (5)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

Continuing the series on product ownership, here’s links to the previous parts: Introduction, part 2, part 3, part 4.

Point 4: A "business sense" and a vision

When I was first thinking about the qualities and how they fit together I had a bit of a hard time placing this one. I felt they are essential, but couldn’t really nail down how or why that would be.  Not just the combination of business sense and vision, but also how a product owner should use these.
The more I was thinking and organizing my ideas, I started to see that they are actually closely related and rely on some of the other qualities I put forward earlier. It brought up some interesting discussions and ideas, which I’ve tried to capture in this post.

Since business sense is a pretty subjective and vague description, I’ll clarify what I mean by that. To me, business sense is all about making good decisions. And in order to make a good decision one would need to understand the tradeoffs, the iron triangle, such concepts as risk vs. value. All these need to be balanced in order to make a good decision imho. So you could sum it up as "the art of making a good decision at the right time". Some of this can be picked up through study and/or experience. What is harder to pick up is "seeing an opportunity", this is where a vision comes in.

A vision could be defined as a long term strategy or goal. Often, it’s not realized overnight but in small incremental steps. Other terms that could indicate a vision is "the Plan" (with capital P), "the big picture",…. Since a vision is some thing like trying to see the future, it means that some assumptions and question marks will be present.

Keeping the above definitions in mind, it’s fairly obvious to see that good business sense is essential for a product owner to make the right decision at the right time. Or at least, to make the right decision with the information known to him at that point. Which to me also makes the decision to gather more information and not make a final decision (given that there is enough time to do so) an equally good decision to "yes" or "no".
A product owner with a well developed business sense should be able to prioritize and make clear decisions about the backlog. This is supported by good communication and negotiation skills, which allow him to convince stakeholders and to get an open dialog so it works, as much as possible, for everybody.

On the vision part, the product owner should be the one guarding the vision, that does not mean he has to be the only one creating it.

I’d like you to think about 2 questions before reading along (and feel free to disagree with my answers below).

  • Can a vision be defended without a deep understanding of the problem?
  • Does the amount of understanding the problem have an impact on refining or adjusting the vision?

I’m inclined to say no to the first and yes to the second. And here’s why.

If the vision needs to be defended, chances are pretty high that there will be an argument on the assumptions and question marks or, in general, on the more vague parts of the vision. In a good vision, those vague parts have been filled in somewhat with a belief, an assumption that is based on knowledge in some way, shape or form. Knowledge, typically drawn from the problem domain. It could be a predicted market change, a new technology that’s upcoming, a desired feature that would give competitive advantage, … . And in order to defend that, you better know what you’re talking about.
On the second question, my answer is yes for a rather similar line of thoughts as the previous. If you end an argument with a need to adjust the vision, typically you’ll be adjusting/refining the vague parts. If you half understand the problem, how will you refine or adjust the solution?

As a final thought, here’s how I see business sense and vision working together. If the vision is your end goal, the business sense makes sure you follow the right path to reach it, with small steps at a time.

12
Mar

Product Ownership (4)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

This post is part of a series on my view on essential qualities for a good product owner in scrum. If you just bumped into this post, here are the previous articles: the introduction, part 2 and part 3.

Point 3: "Great communication and negotiation skills"

Let’s first of all pull up one of my favorite pictures about project management.

The traditional representation looks like this:

BQTS

I prefer  a slight variant to it:

BQTSR

[[small sidestep, skip if you understand the pictures]]
For those that never seen this picture, here it is explained in an easy way.
Scope = what needs to be done
Budget = money, people, hardware, software, …
Time = days till delivery date
Quality = how good the result is (compared to what the customer asked for)
The triangle is sometimes called the iron triangle (there are a few variations out there). Each side and the surface representing one of the aspects. Since it’s an iron triangle you can’t change one aspect without affecting the others.
What the second version factors in is that scope & quality are closely linked. They actually fight for the same area in the triangle, meaning they mostly behave in a "scope+quality=1" manner. The only way to improve both is generally to play with the sides of the triangle to provide a bigger surface.
The other nice thing about it is that it takes out the resources (=people) from the budget aspect. In most development projects, adding developers is not something that is as easy as adding more hardware or software (which typically falls in the budget area)
[[end sidestep]]

As far as I’m concerned, this is one of the most fundamental pictures to understand. The good news is, it’s not rocket science. The bad news, you’ll always be fighting about at least one aspect of the triangle.
The thing that is not on the triangle though, is equally important. Communication! I consider communication the glue that holds this triangle together. I already expanded on communication in an earlier post. What is said there still holds true (hurray), and the key point in this case would be the feedback. Because feedback means exchanging ideas, ideas generally mean new ways of looking at something and eventually coming up with a solution. In the case of our triangle, that solution might be to make a tradeoff that suits all stakeholders as good as possible. Or put differently, communication is a key aspect of negotiating. And both skills are indispensable to come to an agreement.

Another part of reaching an agreement is striking a good balance between complexity and added functionality, based on the time (and other aspects in the triangle) that are set. This is where the negotiation really kicks in. Every stakeholder feels his feature set is the most important, highest value, first to be developed feature. And probably, in their distinct worlds, that could be very true. However, if stakeholder A is asking a feature that is so complex it would take 2 sprints of the team, that would cut off the minor update for B and that small module for C for at least another 2 sprints. Stakeholder A’s feature may bring some added functionality for B also, but C has no benefit. Where do you go from there? This is where it becomes interesting. How do you balance this? (on a sidenote: yes, I love thinking about balancing stuff also outside game design)
This is where the scrum metrics velocity, business value and storypoints (indicators of complexity as I like to see them) come in handy. They provide you with ammo for your negotiations. How you get out of the situation above? I would probably ask A to split up the 1 story in multiple stories first of all, and see how B could benefit from some of those . Since they are split up, they shouldn’t require 2 sprints and complexity on the individual elements should go down. This would open a time for C’s request to be fitted in.

The last part of this communication is something I already touched in part 2 of the series. There is a need to communicate with a wide variety of people. Ranging from hardcore developers to golf playing VPs. The way something needs to be presented to those groups is without a doubt very different. In an ideal world, you would have a product owner that can easily summarize technical detail into executive summaries and can expand executive thoughts into detailed user stories. Read that last sentence again, it’s key to solving many problems. Speaking the right way to the right person is something I tried to get through on my old blog one time (I’m not entirely happy reading back that post now, but still, the idea in there is key to this last statement)

07
Mar

Product Ownership (3)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

In this article I’d like to elaborate on point 2 of my take on good product ownership qualities.
The introduction can be found here, point 1 is here.

Point 2 is: "A good enough technical background"

I know this is a somewhat controversial topic amongst many of the people I spoke to, yet I still think it’s an essential quality.

First of all, how do you define "good enough". A tricky issue and a very subjective matter in my opinion.
Secondly, all of us who have a manager that used to be a technical guru know that he generally misses the deep technical stuff. It’s the reason why most technical managers still like to play with Lego, they make tiny constructions in their office with their pens and paperclips and a lot of them still love to write some piece of software at home. Given all this, I think it’s fair to say that they just miss the "creating" part of software engineering. The technical challenges, coming up with solutions and riding the high waves of new technology and its possibilities. This is one big caveat, and I’ve seen a lot of product owners fail there! (and most people learn it the hard way)

Looking at the natural order of things, it feels normal in the early stages of a project for the development team to drive a lot of the priority settings. They know best what base layer is needed and which components take precedence in order to reach that first thin end to end slice of functionality. They understand what infrastructure needs there are and how low level components (generally those a user will never notice) need to be available before the first features can be built. (sidenote: I am not trying to say they will have a big design up front cycle, but just enough to understand the dependencies). Having a technically trained product owner will help the team out in defending this priority setting to the stakeholders, even though they may not always understand why there is such a need for a "non visible" component or feature.

This being said, that cycle can’t go on forever. At a certain point (you’ll feel it when it’s there) this needs to change and the product owner needs to start taking charge of priorities, based on stakeholder requests. Here again, it takes a product owner with a technical understanding to see when a project is ready for this switch (it’s more of a fade than a hard switch anyway). The risk of not having a technically skilled product owner is that the team will keep running circles around him and develop "cool" features (for developers) instead of listening to what the market is asking for. On the other hand, when a product owner is in his mind still too much of a developer, he’ll happily agree to keep working on those cool features and start ignoring stakeholders and market demands. He’ll drift away as part of the development team and that early stage cycle will never be broken.

So, how would one define the "good enough" than?

In my opinion, good enough means something along the lines of:

  • able to understand technical problems and solutions to an extent that an autonomous judgement can be made on the progress of the development team. This generally requires a product owner who did do some development himself.
  • able to grasp the complexity of a proposed feature and its underlying needs
  • able to understand the high level architecture of a system
  • able to place the development team on an equal level to other stakeholders and make a decision based on business demands rather than on "coolness"
05
Mar

Product Ownership (2)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

Continuing on my earlier post about Product Ownership, I wanted to dig in a bit more in maybe the most obvious of the items on my list.

"A deep understanding of the problem".

The product owner is the main point of contact for all stakeholders. In most projects these are a set of very different profiles, ranging from high-tech to no-tech and from senior VP of directors to working class heroes. In order for your product owner to communicate well with all those parties he needs to be able to give the executive summary of a project, but also to have detailed discussions about problem areas.

Imagine the following scenario. A simple project (if there is such a thing) to develop a piece of data displaying software to track impact of press releases. Your main 3 stakeholders are a senior marketing executive sponsoring the project, some junior on the marketing force who will be mostly working with the tool but hasn’t got any skills beyond viewing a form in access, and a data analyst who is used to slicing and dicing data with custom scripts and queries.

In order for your product owner to be able to effectively communicate with all these people he needs to be able to give the executive summary, work with the junior in understanding his requirements and translating these into backlog items and, lastly, working with a data guru who thinks in hooking custom scripts and plugs to that output and cares about APIs that should be in there.

These are, in my opinion, 3 completely different approaches to be taken. Perhaps the executive summary could be winged with less understanding of the problem, but that would definitely harm the credibility of the project. Working with the junior may require mostly listening and trying to slot his requirements in a timeframe that would suit him best at any given time. The last one will delve deep into the technical aspects. Some of these requests are better taken up with the developers, but the product owner should at all times be a first point of contact in order to shield the development team from deviating from sprint tasks by outside requests.

In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be. He will need to filter out requirements, talk stories through with developers, give regular feedback to his stakeholders and really be just as involved as the development team in order to reach the goals of this sprint.

Since the product owner is equally committed and involved, and will stay involved during the entire project, replacing him is something that would add the same amount of troubles and overhead as replacing anybody in the team. The problem with replacing a product owner is that he is a first point of contact and the "external" interface. Meaning that he doesn’t have a lot of margin to slip up. Any slip up, miscommunication or doubt in understanding the project may (and usually will) result in confusion, angry stakeholders, a mess as to who is the actual product owner. And especially that last part is concerning. One of the most difficult tasks to handle, speaking from experience, is having a lot of channels that are all directly talking to the development team and setting their requirements. The development should focus on development of whatever is needed. It’s not up to them to make decisions about what is a priority to the business. And doing so requires a strong product owner, who understands the problem at large.

25
Feb

Tripit, it just works

By Don Ardonio 1 Comment
Categories: 2.0, software and travel

Albert Einstein once said: "Everything should be made as simple as possible, but not simpler." That’s exactly what TripIt does.

All TripIt does is aggregate all data that you get from confirmation emails when booking flights, hotels, rental cars, … . Adds in bits of information scraped from the likes of wikipedia, the weather channel, google maps, … . It doesn’t require a genius to come up with this, parsing some standard generated emails is a piece of cake. Adding in extra info may require a bit more effort, but still isn’t rocket science. Nothing all that brilliant at first sight, but here’s the catch.

It’s dead easy to use, it’s fantastically thought through and cleverly crafted to minimize your effort. The lazy web at it’s best.

Really, all you do is forward those nasty gibberish confirmation emails. Tripit will figure it out for you. It doesn’t require a lengthy, time consuming, sign up procedure. Since you sent them an email, they know your name and your email address. That’s enough personal information for one day isn’t it?
Once you forwarded your first mail you get a nice return mail (caught by my company spamfilter, but they are aware this happens often, unfortunately). That return email contains a link so you can quickly go check out your travel plan, at that point you’ll be prompted by a "real" sign up, which has a nice skip button. So you can easily use it without having to register. Ever!
Further in that return mail is also a username (your email address) and a password, for future log-on purposes.

Finally, to add in some 2.0-ness, you can share and discuss your travel plans with friends (or colleagues) and figure out who out of your network is close to you. I still need to get some friends hooked up on this, so I can start checking this thing out :)

Conclusion. Awesome, it simply does what it needs to do, without making it complicated, time consuming. And since 90% of the population uses the same top airlines, travel agents, car rentals and hotel chains, it’s able to parse everything most people will ever need (you can still manually add/change if you really have to). I know the year is still long, but this is already a huge contestant for my personal "tool of the year" award!

Also check out the demo videos. It really is that simple.

19
Feb

Product ownership

By Don Ardonio 1 Comment
Categories: agile, development, product owner, scrum and software

I’ve been catching up on agile development lately, more specific, on the scrum methodology.

After sorting through various books, course material and tons of useful talks to colleagues, peers and agile people (not necessarily claiming they are agile but definitely adopting the concepts). First of all, I wish to thank all of these people for the time they took to educate me. I feel at a point now where I have a grasp on how it works and I’m past the steep hill in the learning curve. A good time to look back.

Starting with a statement: "Having seen the waterfall system in action one to many times, I am sure there is a better way". This, combined with my current employer wanting to adopt scrum, is what drove me down this road. Being on the operational side of the building, I have been experiencing product ownership from up close and here’s what I think are important qualities for becoming a good product owner.

  1. A deep understanding of the problem at hand
  2. A good enough technical background
  3. Great communication and negotiation skills
  4. A "business sense" and a vision
  5. No other job

Unfortunately, many companies (including mine), horribly fail at most (or even all) of the above, especially the last one.

In the coming articles, I’ll be elaborating more on those 5 points (= nice hook to have some more articles on my blog :) )

11
Feb

Ardenskie 3.0

By Don Ardonio 1 Comment
Categories: holiday and personal

For the third year in a row, a bunch of former fellow students went on a weekend to the Ardennes. Doing all you expect a bunch of geeks to do on a boys-weekend-out. Upon arrival, the big table was taken by a 24 port gigabit switch and laptops, network cables, gizmo’s and other electronics. Not that we spent a lot of time there, just every now and again setting a queue to borrow some of the friends material.

Friday night was mainly sponsored by Dr. Oetker and Jupiler. On Saturday we took some time out to sit back, chill and enjoy some of the local beverages. I put my hopes on Captain Morgan (original spiced rum), he didn’t disappoint me. It’s nice to just sit in the sun, share time with friends and forget all about the daily worries, even if only for a day. We ended up in Durbuy at night, in a near empty restaurant. After getting our food served, we started to understand the near emptyness of it. The food on it’s own wasn’t bad, but "serve with a smile" seemed an odd concept to the place. Too bad, we did have money to burn if they did some effort.

Sunday, traditionally, ended at Don Antonio for an excellent fresh made pizza.

Memorable facts of this edition:

  • Vicious Vince (aka Poofter) calling the sleeping people at 3am to hear their ringtone.
  • Bladders, Eraser, Crossmol and myself going shopping and buying all of the Mozarella Discs available at the local Delhaize.
  • Bladders having a bit of a jet-lag after 2 weeks Shanghai and so waking up at 7am every day.
  • Azzy doesn’t like pizza, and still he’s our friend :)
  • Many more, not all suitable for publication

Many thanks to the usual suspects for making it a great weekend. Poofter, Rubella, Punkie, Azzy, Apolio, Eraser, Bladders, Crossmol.

14
Jan

Why we will not have senior developers anymore

By Don Ardonio 2 Comments
Categories: development and software

I have the pleasure of working with some people who live and breath software development. Coming from the old days where assembly was new and cool and above all something that made you think about the inner workings of a computer.

Now what makes a software developer senior?

These days it seems like becoming "senior" developer means having a few years of experience under your belt. You can easily have senior guys who never did anything else than php or .NET development. (nothing against php or .NET if used under the right circumstances, don’t get me wrong).
To many businesses this would qualify as someone who would be labeled ’senior’.
I think there’s a bigger issue here. Those new senior developers don’t have that deep understanding that many of the current senior developers have. They never had to be bothered with allocating memory or worrying about limited hardware resources.

The current trend seems to evolve to "if we have an issue with resources or performance, we’ll throw some extra hardware at it". I understand Ruby relies heavily on this principle, after all, development time is more expensive than cpu time.  A fact, just like looking good is more important to Paris Hilton than having something useful to say.

I personally doubt this level of seniority somewhat. They might be very good developers, but in their own language. When it comes to high performance apps and scalability, often it requires an intimate understanding of the inner workings of a compiler, down to bit level.

The "old" senior developers know for every line of code they write what bits move around, how that relates to the heap and stack. They intimately understand Pascal and C strings and the (dis)advantages of both, or why certain algorithms are more scalable than others. Simply because they grew up having to care about every bit in that machine.

Our future senior developers…

These days people often don’t get down to that level of computing. They have fancy things like objects, garbage collectors, excessive amounts of disk and memory available, … . And they often start out with a higher language like Java or C# which makes them unaware of all these intriguing little details that make or break large scale applications. I don’t blame the persons, those who really want will still find all the information necessary to get that understanding of the machine.

I think we should start reconsidering our school system (for Belgium for sure) and start teaching our computer graduates the basics first before letting them have a go at a high level language which takes away a lot of the machine related problems. In their first years, give them an 8086 or an emulator that lets them run assembly. Make them aware of address registers, stack and heapspace, allow them to fool around with 0 terminated strings and the up and downsides. Make them feel the pain, they will even more so appreciate the higher level languages, but above all, they will learn why some things simply require a lower level language.

This is a call to all deciding people on school boards. Don’t try to have a sexy education with fancy new languages, just get a good old hardcore education that teaches what they need to provide the world with senior developers.

12
Nov

2.0 in the Enterprise vs Enterprise 2.0

By Don Ardonio 0 Comments
Categories: 2.0 and communication

2.0 is everywhere these days. It’s not a thing reserved for early adopters anymore.  It’s found its way into politics, the media, marketing and (no surprise) the enterprise. The enterprise, Did it really? Let’s take a sidestep first and explore some basics about communication.

How we communicate

Communication as found on wikipedia:
"Communication is a process that allows organisms to exchange information by several methods. Communication requires that all parties understand a common language that is exchanged with each other. Exchange requires feedback. The word communication is also used in the context where little or no feedback is expected such as broadcasting, or where the feedback may be delayed as the sender or receiver use different methods, technologies, timing and means for feedback."

Let’s just focus on the key ideas I conveniently underlined.

Exchange requires feedback
I’d like to rephrase this for the sake of this post to: Thinking requires feedback. Strictly speaking, exchange is not necessary as one-way traffic exists. We all know the typical all-hands meetings where our beloved CEO, CIO, CTO, CFO and whatever CxO we could find comes to tell us how we are doing. It’s a form of communication where there is very little feedback generally. You are informed of certain events and general status. It does not require a lot of activity from your side and certainly not a lot of thinking. Now when it comes to thinking, even when doing it all alone, your inner self will use language to help your other inner self (or inner selves) understand the problem and you’ll try to describe it. Writing it down, talking it through with others (in or outside your head), … they all require a common platform…a common language.

Language
Probably the single most important thing I know. Language is your gate to the world and is probably worth an entire weblog discussing it.  The thing is, if you can name something there is a link formed in your brain that allows you to think about it. Arguably the single most important thing about language: Language facilitates thinking.  

Information
If Language is your gate to the world, than information is what is behind the gate. There’s literally thousands of information units generated this very moment. And they are all out there, for you to grab, as long as you know what gate to go through.

Let’s now have a look at communication in a 2.0 environment.

Communication 2.0

We’ve spent ages defining language, getting new words and getting our brain to link up everything so we can think about stuff. With great results, no doubt. But exactly what have we been investing in?

As stated above we invested in a lot of words, forming a language. And that language facilitates thinking and we have a lot of information out there. So seems like we did a good thing, we invested in the 3 key concepts. Great job! Go humans!

And yet, there’s something missing. Communication amongst peers does not stop because of language, nor does it stop because of information. It’s hampered by the feedback part.

Just keep your attention span a bit longer on this article and follow me: you and your colleagues sitting in a meeting room, facing the same problem. There may be 4 of you using language and giving each other feedback on bits of information that could add up to a solution to your problem. Great. There’s 4, no doubt brilliant, minds in that room trying to figure out what the hell is going on. Now imagine you would do that with every engineer in your company (assuming you don’t have a 4 engineers company). And even better, let’s take if full scale 2.0. Imagine solving this problem with every mind on the planet that knows this language. Wouldn’t that be something worth investing in? Welcome to 2.0.

Enterprise 2.0?

So there are some tools out there that facilitate communication 2.0. Think about wikis, sharepoint, blogs, … . Which is easy to set up in your enterprise. So here we are than. We all see the benefit of communication 2.0, we have a central wiki page to capture and discuss our issues and to keep others in the loop and allow them to give an opinion. Enterprise 2.0? I, for one, disagree. You introduced 2.0 in your enterprise, but you’re not at Enterprise 2.0.

Enterprise 2.0 is not having the tools in place. Enterprise 2.0 requires an upgrade from Employee 1.x to Employee 2.0. It requires every last one of them (or at least "the critical mass") to actively participate in your company. It requires them to invest time in a philosophy, to maybe pick up the pace on some language from another department. And above all…it requires them to think!

Transparency, open communication, information sharing, collaborative thinking, … to me they’re more than buzzword compliancy for the execs in their speech. They are the next evolution for communication, for better thinking.

12
Oct

Meeting people

By Don Ardonio 0 Comments
Categories: Uncategorized

Lately I’ve been spending a lot of my time in meetings, video and telephone conferences, work related dinners and other social business activities. And it struck me that, after 5 minutes in a meeting you can start identifying different types of people, each with their own capacity. All of them unique and valuable if put to the right use. So, here’s a shot at what I think people in meetings are (or at least, how I’ve met and perceived them).

Mister Social
Tagline:"Have you seen the new hottie on 7th floor?"
Mister Social is not particularly interested in the meeting even though he may have an interest in it. One of his main concerns is usually ventilating his opinion on the latest happenings in the business.

Recommended use:
Grab a cup of coffee with this person. There’s tons of value in knowing what is happening in the business. Catch up, listen to what they have to say, ask for specific topics you care about. Never forget: they like talking.

The Secretary
Tagline:"Could you repeat those last 2 words, I missed them because of a typo"
The secretary will take notes of the meeting. No matter if she needs them or not, she will take notes. And by notes, I mean a literal transcript of the entire conversation. You were coughing during your second sentence? Be sure it’s noted.

Recommended use:
Maximum value in a semi-large group. A too large group she will slow down by asking to repeat everything, a small group can remember the points without a full written transcript. Totally enforces His Shortness as she will write down his statements. When going through these notes just look for what His Shortness said and read around those things for a bit more detail.

His Shortness
Tagline: "So, to summarize the last 30 mins. Very black and white, it’s A or B"
Simply put. This person can simplify everything to a degree you don’t even think about. Reducing a one hour meeting to a few headlines. Very often his shortness has no direct interest in the meeting but is there to support somebody else.

Recommended use:
Not good for detailed discussions. Usually frustrates the Shy Guy bet reducing massive amounts of detail. Very interesting to have in meetings were you need to report to people higher up the tree. Usually those are not interested in the finer details but just want a short concise overview of decision. They know there’s more detail so they know that what you present is black and white, they’ll ask for detail when needed.

The Strong Silent Type
Tagline:"Actually, based on all your opinions, we go this way."
By far my personal favorite. Usually this person will sit there, looking semi-uninterested. The new guys usually wonder why he’s in the room. He won’t speak, he might slightly whisper something to the person next to him, until decisions need to be taken. No bullshit, everybody had their say and based on that this person will tell what the way is and decide. And for some reason, people generally won’t argue anymore. He’s the voice of widsom in many situations.

Recommended use:
Whenever a decision is needed, this guy will be involved, so you can just as well get him into the meeting if you don’t plan on having a conceptual technical discussion.

The Extremist
Tagline: "No, I disagree with your opinion because mine is always better"
Usually so convinced of own point of view that discussions are very hard and irrelevant. Not open for logic or debate, only for people that agree with this character. Can usually only be halted by the Strong Silent Type or somebody that is hierarchically higher and tells them to shut up.

Recommended use:
At all costs, avoid discussions. Whatever bait they use, don’t bite. Either try to scope out the meeting very carefully to not hit their sensitive subject (they will try to force it in anyway) or reveal the strong silent type in the meeting soon enough to get the point of everyone aligned and open a structural discussion.
Try to not have the hierarchy play as this will lead to frustration and more extremist in the future.

The Shy Guy
Tagline:"You asking my opinion? Really? Can I still hide?"
Looking away and not saying a lot. A rookie could mistake this guy for the strong silent type but be sure he’s not. He’s very often the technical guy that understands exactly what the meeting is about. He doesn’t by default ventilate his opinion, and if not spoken to will not speak at all. But once you open his door, what comes out is of great value even though too complex and detailed for a lot of people, not clearly making a point or seeming very structured.

Recommended use:
Get him in when you need detailed information on the project. The hardest part is getting this person to speak. Once you’ve done that the gain is tremendous. It usually seems like every little detail about the project is stored in his head and available within half a second. If you can avoid a discussion between him and his Shortness you’re in for a hell of a ride. He will give you all the detail, his shortness will provide the overview.

Laptop dude
Tagline:"Wow. Cool feature"
Will spend all the meeting typing or playing with his laptop/mobile/pda/latest electronical gadget. Laptop dude is usually a character on top of another type. The trick is to uncover him.

Recommended use:
Get this one out of the meeting. Alternatively unlock the other type, just know that laptop dude on his own has zero value for your meeting.

« Previous Entries
Next Entries »