Keeping My Square Edges

When you hit crunch time on a project, the stress increase has the wonderful effect of showcasing the individual contributions which aren't always apparent. Strengths and weaknesses are illuminated most when risk (and therefore stress) is highest.

You may have heard others talk about stress as a way to weed out those who can't cut it. To identify those people with weaknesses and therefore cull them. Increasing stress works both ways, you can spot both weaknesses and strengths this way. The difference between smart people and lazy people is what they do with this information.

Surely, you can remove people based on their weaknesses, but is that really the best way to get top performers? Not in my experience, and I'm not the only one. A whole slew of authors are writing about this balance between strength and weakness. For example, Now, Discover Your Strengths by Marcus Buckingham, or Teach With Your Strengths by Rosanne Liesveld , Jo Ann Miller , and Jennifer Robison.

Historically, the path to improvement has always been through building up your weak areas, not downplaying them (or better yet, avoiding them entirely!). We give people feedback on the areas they aren't performing, ostensibly so they'll get better.

When was the last time you got a review or feedback that focused on what you did well and only glossed over how you could improve? We have been obsessed with it, and therefore churn out contributors who try and be well-rounded or generic, living in constant fear their weaknesses will be exposed. Because of this close-mindedness, they are never able to pour themselves headlong into their strengths. Like a fly buzzing around, they are constantly distracted by their weaknesses, so they never put full force into their punches.

This is most definitely not how I give feedback. If I'm going to spend energy and time to think about and communicate my analysis of someone else, it is going to be practical. We will celebrate your accomplishments and spend time talking about how you can use the things you do well to really knock peoples socks off and be smashingly successful. Then maybe if you have really pissed someone off or are offensively negligent in some area, we'll mention how you can either avoid those situations, or how to minimize the damage when they happen. There is no sense trying to make a surgical scalpel into a hammer.

For my own performance, the same rules apply. Certainly I am critical of my failures and short-comings, but only as they distract from my ability to perform with my strengths to their maximum potential. Rather then dwell on not being a white guy with shiny, gleaming, perfect teeth, bushy hair, a perfect handshake and who looks at home in a suit, I play my geeky, straight-shooter, mushroom-like role to the hilt. And then I bring a white guy with full hair, a nice tie, and a firm handshake to the meeting. He talks his white-guy talk and does the secret handshakes so I can focus on the important details necessary for us to actually deliver.

When we try and force people into being generic and "well-rounded" we are really asking them to knock off their typically square edges so you can shove them into your round holes. I like my edges and try to respect the edges of others.

No one can do it all. Recognize what you can do really well and then avoid or compensate for the rest.

The Line Between Good And Great

Staffing a project can be a unique sort of puzzle. It can be very similar to the exercise many start-up companies go through trying to find talent. The problem is that it can be really hard to recognize talent on paper. And when it comes to building solutions or delivering real business value you often need engineers who can do more than just cut code. Consider what Paul Graham wrote:

But when I think about what killed most of the startups in the e-commerce business back in the 90s, it was bad programmers. A lot of those companies were started by business guys who thought the way startups worked was that you had some clever idea and then hired programmers to implement it. That's actually much harder than it sounds—almost impossibly hard in fact—because business guys can't tell which are the good programmers. They don't even get a shot at the best ones, because no one really good wants a job implementing the vision of a business guy.
-- excerpt from The 18 Mistakes That Kill Startups by Paul Graham

This is a spot on concern as it relates to start-ups, and is a pretty good summation that the world at large has with separating real technical talent from mediocre technical resources. To help with this, I've written down what I consider to be the key points that separate the great engineers from the herd.

First and foremost it has to be the Love of the Game. Some people call this Passionate or Enthusiastic. Regardless of how you refer to it, you know it when you see it. When an engineer truly likes being an engineer, they exercise that passion whether they are getting paid for it or not. These are the people who light up when they have a chance to explain some nuance of a solution or problem they are working on. Even when polite company would have recognized that a topic was becoming to specific or technical and gracefully glossed over the details, an engineer of passion may just not care about the social graces and bore full steam ahead unconcerned.

The inverse of this is the engineer who has a job. The get enough tech talk at work and go to "training" when they are told they need to learn something new. Engineering pays their bills, if they could make as much money doing something else, they would. When you see someone who has had the same job for years and years, has worked with the same technology, on the same application or platform and doesn't see the need to change, recognize that they may be competent but they lack the potential for greatness.

An enthusiastic engineer naturally leads to a Self-Reliant engineer. When you love something you want to know all about it. You genuinely like that there is always something new to learn. With engineering, there is the added benefit that technology is always evolving. When their heart is in it, nobody has to tell an engineer how to keep up. They do it naturally, on their own. They know that the best way to learn is just to leap in and embrace it. They don't wait for someone to send them to training, they experiment and create of their own accord. When they come upon a new technology they don't wait for the explanation, they don't need to be taught, they just jump right in and learn.

The inverse of this is the engineer who constantly needs help. They need the complete manuals, they need training materials, and samples. If they are always talking about how difficult something is to understand because of the lack materials at their disposal, if they want to get trained before they embark with a new technology, they may be competent, but they lack the potential for greatness.

Engineers who are or can be great, seek to be Wise. Anyone who has learned to be self-reliant understands (even if only subconsciously) the difference between Wisdom and Knowledge. Knowledge is the set of facts, data, or concepts that can be learned, taught, understood. Wisdom is the application of knowledge. For most people, with experience comes wisdom. The more they attempt to apply their knowledge to the world, the more they the learn about which knowledge is meaningful and practical. Knowing what you need to know and how to identify what you don't know in a particular circumstance is the most useful thing to understand when faced with the new and interesting. It is this constant self-refinement and search for the application of knowledge which can easily lead engineers to be considered socially inept. Socializing is often about compensating for differences, and celebrating commonalities and trivialities. This is completely juxtaposed with the engineers pursuit of practicality and usefulness. Engineers who are great will be able to switch their communication style between the practical and the social when appropriate.

The inverse of this is the engineer who knows only for the sake of knowing. When the emphasis is on the tests they've passed or certifications they hold, you might take a closer look. If they can't focus quickly on the criteria for success (or risks of failure), or if they aren't objective about the usefulness of their new widget then they may be competent, but they lack the potential for greatness.

To really leverage these talents an engineer should be Diverse, they should have a wide Breadth. Even early in their career an engineer with great potential will find opportunities to jump from problem space to problem space. They will find that they need more than one toolset on one platform. They'll have experience in applying their knowledge to more than one type of opportunity or industry. Any engineer who is truly experienced, will resemble an onion with layer after layer of different experiences, most of which won't be covered by a resume. They will invariably be able to find parallels with their past experiences, and will constantly be remembering skills and aspects of their work that are applicable now but which weren't significant enough to write into their cover sheet. To a great engineer, the fact that they had to write a multithreaded performance test harness, or an attribute injection lex, or an exception word map isn't really important. It was the sum of the parts they delivered which was interesting. To them it is just an assumption that to get the end result they'll have to do all the other things in between. Many of these in-between problems are significant and meaningful in other contexts all by themselves.

The inverse of this the engineer who spends all their time in the parts or focused on one technology, platform, or industry. They know all about how to make NUnit do interesting things, but have never shipped anything. They know how to build data entry applications but have never concerned themselves with how the reporting system does what it does. That database guy who doesn't really know how the front-end works should give you pause. The UI guy who draws brilliant graphic but stays away from "the backend" may be competent, but they lack the potential for greatness.

A caveat with this last one is that we all have specialties. From time to time we all need a real pro at just one thing, and it can take time to truly master some aspects of engineering. The distinction isn't that they don't have a specialty, it is that they have branched out into all the supporting and complementary areas. If you want to truly master something technical you need to understand how it overlaps with, supports, or is supported by other technologies. An amazing looking UI that takes to long to boot up, or doesn't integrate seamlessly with its data providers will ultimately be useless. Likewise the most efficient library design is worthless if consuming engineers find it hard to use.

Being having these other attributes becomes less useful if the engineer isn't Social. To be valuable long-term they need be someone that people can work with and form relationships with. In any environment, Trust is essential to mitigating risks and allowing velocity to increase. Further, independent contributors without a sense of community or social responsibility will leave their biggest value on the table. It is one thing to be able to do a thing well, it is much more valuable to be able to teach others to do it equally well. Sometimes this is referred to as leadership or mentoring but ultimately it is about being able to inspire trust and earn rapport. Often this is a latent talent that can be spotted very early by contributions that person makes to the community at large. A willingness to be trusted, a desire to connect with others about their contributions are often signs of a valuable resource.

The inverse of this is the engineer who only works independently, has trouble establishing rapport or eliciting trust, and isn't interested in the contributors around them. If they don't see the value in community boards, hoard their specialized knowledge and aren't interested in teaching or mentoring, then you have some warning signs. The loner who solves hard problems but doesn't care to explain how and is less effective as part of a team may be competent, but they lack the potential for greatness.

An engineer with a majority of the previous traits will likely be Opinionated. Simply put, the pursuit of greatness requires an ability to recognize when things are not great. An engineer who doesn't have strong preferences and habits is neither going to be decisive nor efficient. Efficiencies are only capable when you can rely on habits, known patterns, and economies of scale. These things require some level of standardization and best practices in place. A key trait of someone with the potential for greatness is that while they may often be wrong, they are rarely in doubt. It is this confidence in their ability, proven by their experiences, backed with their reason and intellect that allows them to make progress where others have stalled, to act quickly while others are paralyzed. It isn't that they are rigid in their preferences and opinions, quite the opposite, they may change their course much more often than seems normal. Being able to have an opinion is important, so is being able to change or let that opinion go when appropriate. The best engineers can assimilate the opinions and preferences of others which allows them be more accurate in their reasoning, even on an unknown landscape.

The inverse of this is the engineer whose opinions are too rigid, who holds to standards and habits long after the need or advantage for change is apparent. If the mind is too closed, reason will inevitably fail. Consider the age of toolset the engineer chooses and the terminology they use. If you arbitrarily alter the assumptions in a problem space and witness a lot of discomfort or inability to change tactics and approach quickly then you should be cautious. An engineer who presents the same tools and approach to every problem may be very competent in that space, but they lack the potential for greatness.

This list is more a guide to potential. The wrong situation, personality fit, or environment can make a great engineer useless. A healthy environment can take someone with mediocre skills but strong potential and give them an avenue to be great. Of course, that's just been my experience, YMMV.

Hopefully this list can help you spot competent engineers if that is what you are looking for; they certainly have their uses. After all, everyone can't meet the standard of great. You don't have to staff your team or project or company with only great people. If you have competent people, and a few people with the capability to become great, then the right environment will allow their potential to be realized. If you can't afford the risk, get at least one great engineer, and let them find the other competent engineers to round out their team.

Have Whip, Will Travel

In my dialog with other professionals about project performance I identified two distinct roles that seemed to emerge reliably throughout every engagement. The Manager and the Driver. The Manager usually interacts with the Client or between teams and sets direction. The Driver is usually just a higher-form of Grunt Boy who is brought in to deliver on the goals and direction established by the Manager. If your software project were a pirate ship, the Manager is the Captain and the Driver is his First Mate who whips the crew to shreds, yelling at them to "Row Harder!" and so forth.

One of my most common delivery roles is being the Bad Guy. The Driver, not the Manager. It makes me almost universally despised and loathed. Of course, since the Driver is a role that someone must play on any aggressive project, when I am willing to step up, it makes me a critical necessity without which little to nothing would get done.

In my experience the difference between the Driver and the Manager rests on a couple small factors that are easily observed. Having been in both camps at various times, I can tell you that there are pros and cons of each, and each is absolutely essential at various times and in different situations. The hard part is we often don't know we need one until we really need one. We also are typically annoyed the greatest by their respective behaviors when the role is being performed most efficiently.

• Drivers realize that the maximum allowable time lag for a dialog is measured in seconds. Managers maximize communication lag to allow for spin and messaging.
• Drivers demand transparency and enforce individual accountability. Managers package information for audience appropriateness, and assign credit or blame.
• Managers review. Drivers do. I can't think of any more poignant or direct way to express this one.
• Managers buffer personalities and styles. Drivers crash people into each other.
• Managers plan and negotiate; schedules, costs, resources, environment, politics. Drivers push forward and either stop at or run over obstacles.
• Managers put the work of others into context and therefore create Value. Drivers are less concerned with showing Value; the tend to be motivated more by Accomplishments (regardless of Value).

Next time you are struggling with someone in leadership around you, run through the list and figure out what role they are playing. When you see someone playing Manager, give them credit for tackling the squishy, important stuff. When you see someone playing Driver, put on a helmet before approaching.

If you want to be liked, be a Manager. Don't sign up to a Driver unless you've got skin thick enough to handle it.

Deming's 14 Points

Everywhere you look you can find ideas and checklists that help you bring transformation to your company or your life. For organizational transformation specifically, none has stood the test of time like W. Edward Demings, 14 Points.

1. Create constancy of purpose.
2. Adopt the new philosophy.
3. Cease dependence on mass inspection to achieve quality.
4. Minimize total cost, not initial price of supplies.
5. Improve constantly the system of production and service.
6. Institute training on the job.
7. Institute leadership.
8. Drive out fear.
9. Break down barriers between departments.
10. Eliminate slogans, exhortations, and numerical targets.
11. Eliminate work standards (quotas) and management by objective.
12. Remove barriers that rob workers, engineers, and managers of their right to pride of
workmanship.
13. Institute a vigorous program of education and self-improvement.
14. Put everyone in the company to work to accomplish the transformation.

-- Excerpt from Chapter 2 of Out of the Crisis by W. Edwards Deming

As someone who is all too often attempting to drive transformation in various organizations, I have found my internal dialog referring to this list often enough.

As helpful as these words have been for understanding how to implement transformation in an organization, I have found his words on how to bring the individual into the process even more empowering.

The first step is transformation of the individual. This transformation is discontinuous. It comes from understanding of the system of profound knowledge. The individual, transformed, will perceive new meaning to his life, to events, to numbers, to interactions between people.

Once the individual understands the system of profound knowledge, he will apply its principles in every kind of relationship with other people. He will have a basis for judgment of his own decisions and for transformation of the organizations that he belongs to. The individual, once transformed, will:

• Set an example
• Be a good listener, but will not compromise
• Continually teach other people
• Help people to pull away from their current practice and beliefs and move into the new philosophy without a feeling of guilt about the past

-- Excerpt from Chapter 4 of The New Economics for Industry, Government, Education by W. Edwards Deming

For myself, I am often challenged on my desire to keep quality high and to not compromise on language or vocabulary during discussion. I will adapt my language and alter my point of view, but always seek for consistency and correctness in speech. Often times the less deliberate find this strict discipline confining or frustrating. For me it is the cost of quality and effectiveness.

Thanks for validating me, Deming.

Size Does Matter

As a consultant I am often put on the spot for specific answers and decisions for very ambiguous and undefined problems. Sometimes they want the finish date for a project, or a how much it will cost to build some gigantic piece of software. Whenever you faced with taking a stand on something that is very unknown you should address it head on: "I do not know."

Many people have a problem being able to admit their ignorance. One of my mantras is often misinterpreted to mean I always have THE answer (Often Wrong, Never in Doubt). What must be realized is that I freely admit I don't have THE answer. That is not the same as not having AN answer. My answer might often be that I don't know, but you'll get it clearly and quickly when that is the case.

The goal with always having an answer is avoid paralysis and continued chaos. The goal with admitting ignorance when appropriate is to illustrate the care and attention to detail that you should have for your decision-making. It helps to be Articulate, but only if you are first Deliberate. So being deliberate about how you provide answers is critical to keeping credibility and integrity.

In addition to showing that you care for quality of your responses, you can show that you care about the input of others by asking questions to clarify what is being asked or what will make a decision acceptable. Take the time to understand what a good answer would be, how precise or concrete the details must be, what is at stake in the decision. Being able to clarify the factors that go into your answers and responses is important for being able to defend or justify your position.

This technique of acknowledging ignorance and seeking to understand doesn't just help the quality of decisions, it can actually help ensure you are making forward progress. Breaking big issues into smaller ones, dissecting tasks into dependant steps, is a great way to not get sucked into Analysis Paralysis.

Even in your personal life, if you have a challenge that seems overwhelming, start distilling it into small steps and milestones. Then you can move forward by focusing on just one step at a time.

At work on software projects we use 2 hour increments and daily milestones. Anything more is just too big to digest. By using small units of work, we stay nimble and can celebrate victories more often. Instead of assigning work that takes days, I assign work that takes hours. It takes more effort on my part, but my engineers aren't able to procrastinate. The productivity can stay very high and because I have to understand the work at a much more granular level, the outcomes are easier to predict.

A Flock of Stupid

There may not be an "I" in TEAM, but there is one in PASSION.

In his book Re-imagine!, author Tom Peters said, "We will win this battle... and the larger war... only when our talent pool is both deep and broad. Only when our organizations are chock-a-block with obstreperous people who are determined to bend the rules at every turn..."

James Surowiecki, is the New Yorker columnist who wrote The Wisdom of Crowds. This compelling book is about how groups of people operate compared to individuals. He sets the context by discussing how many animals and insects increase the sophistication of their behavior by acting in groups. The concept here is that sets of simple interactions following straight-forward rules can produce very complex behaviors. This theory applied to birds is known as flocking. For many insects it is called a swarm.

Paradoxically, the best way for a group to be smart is for each person in it to think and act as independently as possible.
-- The Wisdom of Crowds by James Surowiecki

After going through the background he then illustrates how all these theories break down when you get to homo sapiens. His premise here is that we present the opposite behavior. Essentially, in contrast to the animal and insect kingdoms, the more interactions that are involved in our behaviors, the less sophisticated and less intelligent the behavior becomes.

All this is not to say that groups cannot be intelligent, it just requires that we aggregate the interactions and don't attempt to reach consolidation or consensus. To put this another way, it means that you should take the average of the individual responses or inputs, don't try and work together to formulate a single answer. He goes into great detail with lots of examples that are very interesting.

He doesn't stop there thought but extrapolates several other ideas as well. For example, if you are aggregating input then you can increase the effectiveness of the group by increasing the diversity of the group.

"Diversity and independence are important because the best collective decisions are the product of disagreement and contest, not consensus or compromise. An intelligent group, especially when confronted with cognition problems, does not ask its members to modify their positions in order to let the group reach a decision everyone can be happy with. Instead, it figures out how to use mechanisms--like market prices, or intelligent voting systems--to aggregate and produce collective judgments that represent not what any one person in the group thinks but rather, in some sense, what they all think."

Leaping forward from this it becomes clear that team thinking can lead only to incremental improvements, because it will prevent revolutionary ideas, those thoughts which are by definition outside the group norm.

If you want to create a formidable team then you must acknowledge that the mission of the team is to create a supportive environment for a collection of individuals. Team members must have their own unique voices and perspectives. The team is empowered to encourage the individuals to pursue their own ideas, not to force consensus and keep everything warm and fuzzy.

The saying that "None of us is as good as all of us" is crap. My biggest reward from people I mentor is when I hear them say that not only are they as good as their group but they are actually better at specific thing X or Y. Only then will I know they have the confidence and will to head the lemmings off at the pass when they're all heading off a cliff.

Feedback Fouls & Faux Pas

How do you provide feedback to the people that work for you? How does your company review employees? Do you have a cyclic review period tied to compensation? Does everyone scramble around every 6 months or so to collect and deliver evaluations of each employee? If so, I feel sorry for you.

If the people you work with every day aren't providing you feedback daily, then they have no right to show up at the end with a list of could-haves and should-haves. What kind of teammates hold back any information that truly would improve your behavior? The progress you make to improve is something that doesn't happen with a summarized list once or twice a year. It is a daily grind that demands you get unflinching, constructive, and contextual feedback from your peers, your leaders, and your subordinates. Anything less is just an exercise in whining and collective finger-pointing.

The same is true for customer feedback. Customers tell you when you aren't behaving as they would like. If they don't it is because they recognize other forms of value you might bring. Or they ask you to leave. They vote with their pocketbook every day. Just because someone has rough edges doesn't mean the customer doesn't see the value in that edge. Now mind you, I'm only talking about singling out individuals here. Success as a corporation or on an engagement basis still absolutely requires that you measure their satisfaction at intervals, and definitely seek engagement feedback with post-mortems and such. Even with your peers and teammates these are good practices. The point of those exercises is to collect information corporately, meaning "as a group" or collectively. It allows the aggregate experiences, the sum of the value-exchanges, the result of the processes and approaches to be refined and improved. They can't successfully be used for isolating out individual performance if for no other reason then the ineffectiveness caused by the time-delay and lack of context. What was uncomfortable or outrageous in one context can be completely justified if the delivery priorities are met. You have to examine the parts as they relate to the whole, not independently. You can't separate the means from the ends, even if they don't always justify each other.

When it comes to personal feedback I would go so far as to say that if you have feedback to give someone and you don't provide it in a timely manner, then you are the more at fault. Consider how we excuse the behaviors of others around us all the time. There may be some aspect of the context, the value-exchange, or their behavior that balances things out. There may be something there in the moment, at the time you noticed the behavior that allowed you to see past whatever negative things you'd like to complain about. Maybe you emphasized with the situation at the time, or made allowances because you noticed other positive side-effects. As you watched the reactions, maybe you agreed with the messages or appreciated someone else's unique predicament. Or maybe you were just lazy. But if in the moment, when you noticed the behavior, it wasn't significant enough for you to speak up, then you can't bring it up later and beat them over the head with it, out of context. When you no longer have the balance of the empathy, or the clarity of the context, you can't assume you are really being objective. Was the intern rude to interrupt your meeting, or did he save you thousands of dollars by catching a costly mistake just in time? Was voicing objections to a potentially bad decision a good idea, or inflexibility? It may be that she is defending her decisions because she is self-serving, or perhaps she realizes that not speaking out now will open a door for future liability? As any good consultant will tell you, the right answers always start with "it depends".

All of this is not to say that it isn't possible to notice trends over time. Sometimes behaviors are subtle enough, or we are lazy enough, that we need to see the same patterns repeated before we notice the effect. It may have to occur several times before we have enough data points to take umbrage. This is very realistic and understandable. But still we must realize that that at some point, you did know. You became aware and cognizant that the latest data-point was the one that showed the pattern. You witnessed the latest exchange, you noted the recent behavior, you said to yourself "they're doing it again". It is at that moment, that you have a choice. Give the feedback, or store it up as ammunition to blast them with later. My suggestion is: don't be a punk.

Of course, just because I think feedback should be frequent, contextual, specific and time-sensitive doesn't mean I think you can interrupt processes, dialogs, or other exchanges just to give that feedback. I am not ignoring or dismissing the necessity of propriety and appropriateness. Sometimes you do need to set something aside so that progress can be completed, so that events can unfold, and this is fine. The trick is not to let things go. Don't let them fester and build up with time. Find (or make!) time to engage that person and encourage them with what you have noticed. If you care enough to give them feedback, if your feedback is meaningful enough that you expect it to be well received, then it needs to be delivered swiftly and surely. If it is something you can wait months to tell them about, it probably isn't worth spending the time on. If you can't be bothered to help them alter their behavior by giving them feedback right after the meeting that went so poorly, then it must not have been so earth-moving that it needs to come up again at review time. If your feedback is truly impactful, you owe that person a chance to show that they can take your feedback and apply it. If it was just anecdotal or just your opinion on things that might somehow in some subtle or subjective way make them more "successful" (whatever that means!), then you surely can tell them in a forum that won't adversely affect their salary and standing.

In my mind, your compensation should be appropriate for the value you bring the company, not fluctuating to the randomness of some subjective standard. Getting evaluation feedback that helps you improve should be an every day occurrence, not a special event. If you only get a few special events they should be encouraging and uplifting. So if you want to use an evaluation result as a reward or incentive, then direct it for that purpose specifically. Linking it with personal development improvement items sends too many mixed messages and often only reinforces the bad behaviors and laziness of managers unable or unwilling to invest in their individuals.

Does your organize only provide for evaluations at milestones that are spread far apart? If your role requires that you review others, perhaps you could try to focus on and celebrate the positives. Use the special occasion to encourage and build up, rather than tear down. There will be plenty of time to talk about how they can improve at a later time. Like tomorrow. And the day after. And the day after that.

The Juice vs. The Squeeze

In my recent work-life, I've been noticing a recurring conversation. Mostly the subject of the dialogue goes by names like Motivation, Incentive, or Compensation. At the heart I find they contend with the same concepts, they just take different forms depending on the vocabulary of the participants.

How do you decide that the cost to you for expending your labor continues to be worth whatever you gain by doing so?

How do you know if the juice is worth the squeeze?

The flip-side of this equation is equally important to understand when you are in a position of leadership. Regardless of the words you use, the same exchange takes place. You might call them resources or employees, contributors or individuals, children or parents, spouses or significant others, all these are participants in the various value exchanges we participate in every day. You might call it money, freedom, pleasure, power, contribution, or simply productivity; these are all substitutes for the value in a value-exchange.

When you are trying to get productivity out of contributors (or money out an employer) it only works successfully if the value systems between the two parties have some overlap that can be shared. You can't expect an employee to work for free, you can't expect to be paid if you haven't delivered.

It seems like these value-exchanges would be simple, but in reality it's what causes all the office tension and much of strife in our personal relationships. My current perception is that this is because we tend to hide our true value-systems. We hide them from each other, from our employer, our spouses, and most noticeably from ourselves.

Think about the last time you saw someone complaining about not getting paid enough to you, but then asking the boss for more training, or more vacation time. I witness people hiding their value-systems all the time. They talk about having "interesting" work, when they really only want more responsibility. They complain about working overtime, when they really just want to choose their own working hours.

Even the simple exchanges are difficult enough but when you add the group dynamics, and the comparisons that are invariably made between different value systems, things get even more complicated. You can hardly give out raises to satisfy a person who is driven by financial incentives if most of your workforce is motivated by non-monetary benefits. You can't expect to motivate people with extras and intangible benefits if the financial incentive is non-existent.

My friend said it very well the other day:

I will behave exactly as you incent me to. -- H

If you aren't getting the response you want from your employees, or your boss, from your spouse or from your kids. Then you might examine the value-systems being exchanged. A good analytical review might really surprise you.

Algebra or Calculus?

The great thing about traveling to for work is when you get to spend time in another country with people you don't normally get to spend time. The time difference, the stress of the unknown, and the lack of sleep is a powerful combination for creating some strong conversations.

One of my friends last night brought up the subject of leadership styles. Specifically, we were discussing how much help to provide people who are struggling. Do you provide them all the answers, and cover for their short-comings? Do you hold them accountable which invariably leads to some very upset and stressed individuals? Is there somewhere in the middle between direct involvement and letting them work things out for themselves?

We didn't necessary arrive at conclusions, and I don't think we were trying for any. It was more one of those casual conversations where you can see people working out what they think by talking and questioning.

To be in the weakest camp is to be in the strongest school.
- Heretics

For my own part, I think it very much depends on what is at stake in the endeavor. If very much is to be gained or the downside of failure isn't necessarily survivable, then stepping in with more direct involvement is probably warranted. On the other hand, as a matter of course, I tend to give people plenty of room to work things out themselves. Some might even say I give people too much wiggle room.

The funny thing about leadership is how different it can be than management. In some ways, managing people is much like solving an algebra equation. The variables are fairly limited and constrained so a solution is pretty easy to work towards regardless of how complicated it might at first appear. Contrast that with leadership which to my mind is more like doing calculus. You have to solve for multiple functions simultaneously and while the simple algebraic operations come into play, they are manipulated in much higher orders.

In any case, I do consider it a privilege to discuss these topics when approached. There is still much to learn and refine.

The Middle Always Costs More

I am such a hypocrite.

On the one hand, I strive for consistency and transparency in my walk. On the other hand, I flake out and take the lazy lane with remarkable alacrity.

It just seems to me that you shouldn't be able to hold up standards and faith and then so willingly succumb to numbness when you cease to strive. Sometimes all it takes is a random conversation you bring on to pass the time that leaves you muddled, unmanned, unmade.

They believe in nothing,
We believe in One Thing.
-- Fire by The Supertones

It isn't that I don't know that I should be striving, it is more than I find ways to talk myself out of it without even realizing it. My fear of being judged by some men causes me to let down others. I back down from situations where backbone is required. My callow cowardice comes to light every time I choose form over function, appearances over outcome.

At one time I would have held my ground and been thought difficult, uncouth, unkempt, or even rude. But I would have said the needful, averted the disaster, and ultimately delivered. Not today though. Now I hold my tongue and watch the ships slowly sink. Now I play the negligent Nero as the flames rise and my desire to remain polite and politick binds me to inactivity.

More and more I act like those I once proclaimed as wrong. They "Don't Get It." was common in my vocabulary. The proverbial They were always selling out success for short-term gain, and I snickered at them. Today I find myself on the brink of that same shortcoming. Fear freezing my insides, I smile instead of speak. Astride the fence, I see both pastures and realize the grass grows green on either ground. The only difference is that one you rent at exorbitant rates and other you own free and clear. Why do I even consider leaving the land of free? Perhaps I find that price too high?

You can deliver messages with care and kindness but if you cannot make the hard decisions, hold fast to accountability, and push forward one and only one agenda, you will fail. There is more to being a Leader than Management. Sometimes to deliver you will not be well-liked, this I've known from much time past. Now I am learning that being well-liked generally means you compromised if you delivered at all.

They always told me come to Middle. Find that spot between Productive and Polite and it will be Perfect. To which I now say Pppfftttpppttt. The Middle costs more. If you are going to be Polite, recognize your irrelevance. If you are going to be Productive, accept you will be outcast. It is better to be tolerated out of respect, than desired out of shallowness that disappears in stress.

No more Middle for me.

Tenets of Appreciation

What makes you feel appreciated? Do you know your Love Languages (read: The Five Love Languages by Gary Chapman)?

Sometimes when I am out and about in public, I can't help but overhear the conversations of those around me. It's not that I'm intentionally eavesdropping (well, most of the time), it is just that I really like to pay attention to what is going on around me. During one snooping session in an airport recently I noticed a couple discussing her specific position within the company for whom I presume they both must work. At first it simply sounded like the same old whining you've come to expect always accompanying our American sense of entitlement.

As I listened with one ear, reading a paper out of one eye, the phrases started to become misaligned with how people normally register their dissatisfaction. It made me want to know more about why we she wasn't feeling particularly motivated or appreciated even as her friend effused praise on her obvious contributions to him and others in their workplace. If he was so readily able to supply evidence of her worth, why was she questioning her place? I wondered if her boss was aware? If she worked for me, would I have been aware? As is typically the case, I abandoned my attentiveness choosing instead to pursue something of more immediate self-interest. Namely, what did I think about her predicament? What would I do in her shoes, her friends sneakers, her team leaders clogs. (Okay, they may not have been clogs, but who knows.)

In dissecting the situation I had stealthily stumbled upon, I was reminded of some of the guiding principles in my own philosophy on motivation, personal career choices, and leadership.

I have to believe that I am relevant, valuable, and have an impact.
I will perceive this through the respect they accord, and the riches they afford.
Otherwise, it is as the author said, "[S]he's just not that into you."

These simple words guide my thinking whenever I begin to question my place and position. When responsible for the success of those working with me, I try and recall these principles and apply them to the value proposition I create for them.

What I find most useful about such a simple set of tenets, is that they can be applied regardless of the specific drivers and motivators of each individual. The indicators and behaviors that will show value and impact may be different from person to person, but their existence will be consistent. One mans riches take shape in cash, another in experiences, and still a third in freedoms.

Regardless of what the specific circumstances are, it can be very telling to ask yourself how you are measuring up? Are getting what you need? Are you making sure the people you are responsible for are getting what they need?

Consistency is Critical

One of key tenets that I try to follow is consistency.  The reason I see most people being inefficient or unproductive is that they are not consistent.  Even when they realize they will be doing something multiple times, they don't take time to standardize.  Using standards and following patterns is at the core of my philosophy.

Regardless of the end goal, if you find yourself doing something more than once, standardize it. Having a fixed way to proceed will:

• Improve efficiency - efficiency is the key to maximum productivity.  Using standards and following patterns means there will be less decisions to make and allows you to learn from the mistakes of others.  When producing something it generally means you can build on existing work instead of creating everything from scratch.
• Increase quality - when you follow patterns and adhere to standards then things become reproducible.  Failures can be found and fixed quickly.  It becomes easier to trust the processes when they function deterministically.  You will have more trust in a product with many predictable bugs, then a product with few apparent bugs that behaves unpredictably.  Generally speaking, trust is a measure of how we perceive quality.
• Unblock communications - when you agree on terminology, the steps in a process, or the definition of concept, you can articulate more concisely and reliably.  When you listen, you will be able to trust that the words convey the content and the intent in equal measure.  You will be able to express your point of view accurately, with fewer restatements and misunderstandings.

From a management standpoint, following patterns and creating consistent processes means that the we can share information without guessing about the intent or spending time on the packaging.  From and engineering perspective, this consistency translates into understanding the code produced by each team member.  For the entire team, when we don't know something, a standard will often save us from having to ask someone and waste time.

If you are a member of a team, you lead a group, or are an executive in charge, striving to create consistency will increase your capability.

Scheduling As An Art

This weekend I had the opportunity to crack open my PMI resources.  Generally I keep quite about it, but some time ago in years gone by I held a PMP certification after extensive training.  After learning and practicing I found most of my work held a more technical slant than that found purely in the project manager space.  The funny part is that the blokes I'm currently working with seem to think they wrote the book on the subject even as we flounder with something as simple as a project plan.  Not that a project plan is ever really simple.

Of course if you have too many cooks, the menu is under debate and no recipes in sight even for the dishes you can agree on, expectations for gastronomic delight are minimal at best.

Keeping a friendly face on the stewing brew was sufficient cause for me to brush off my books for a surface scan on the subject of scheduling.  It really does take skill and will to pull a proper plan together.  Then again so does life.  In the words of Samuel Butler...

Life is the art of drawing sufficient conclusions from insufficient premises.

My two step formula for creating a clear, defensible, precise plan that can easily be tracked, is straight-forward to modify, and is concise enough to explain?

1. Turn on automatic leveling.
2. Lay out the titles and durations of each task.
3. Link tasks to their predecessors.
4. Assign resources.
5. Stop screwing with it.

It's not incredible sexy but I've used it hundreds of times and it works.  Start adding steps, and you are sure to take a wrong one.

The point I make by the above over-simplification is that laying out the plan shouldn't be a grueling ordeal of creativity and algebra.  A clear organization of fundamental data points will usually yield way more value than lots of groups, custom fields and extended analysis.

Having said all that, once you have to start tracking work, all bets are off.  The skills are different, the tools can be different, and personal style is a huge factor in the success of your choices.  Which is why I tend to be very simple when figuring out what needs to be done, how long it will take, and how many resources are required.  Because once you start executing, all the rules are changed, the race has begun and you need all the energy you can afford.  Plan simply, so you can simply succeed.

Capable of Being

Sometimes I don't pay as much attention to my feelings as I should.  I'm not exactly the most empathetic of people at times, but I seem to find ways to sell myself short most of all.  Being senstive to kinesthetics is a huge aspect of being self-aware, but it's probably my weakest area.

From time to time, I'll find myself doing things I don't enjoy, backed into corners I don't want to be, supporting things I don't believe in.  As I wake up and look around and ask "why am I in this?" it seems that not tapping my feelings is one way I got off track.  For someone formally trained like myself, that's a harsh reality.  So I'm going back to the basics.

The first step is to Identify. What are the feelings and reactions that don't quite seem to fit?  What doesn't smell right?  If things are jumping out at you, look for those endeavors where you got started fine, but lacked follow through.

The second step is to Orient.  Is the feeling applicable to who you were, who you are, or who you want to be?  Is it something that is just familiar and habitual?  Once you understand which way the feelings are oriented, pushing you into something, pulling you away from something, you can respond.  It is just as common for a fear to be a good thing pushing you to commitment and intensity.

The last step is to Imagine.  Once you have opened your sensitivity to your feelings and intuition, and you have oriented that feeling with an action or a behavior or a decision, then you are free to imagine the results of your responses.  This most often takes the form of "What would happen if...?"

This little question, when built on the clues about what you want in your life given by your intuition and feelings, is the key to planning your response.  Start by sticking to what you enjoy.  What makes you happy.

The most common response to this, is that "I can't make a living doing that".  Do it anyway.  Do it in any way that you can.  The happier you are, the more you will accomplish.  The fuller your life will be.  It's surprising how little in life we really need when we are pursuing that which we truly value.

Sometimes the thing people are most frightened of is who they are capable of being. They are simply afraid of how powerful and brilliant they can truly be.

Our deepest fear is not that we are inadequate.
Our deepest fear is that we are powerful beyond measure.
It is our light, not our darkness, that most frightens us.
We ask ourselves, who am I to be brilliant, gorgeous, talented and fabulous?
Actually, who are you not to be?
- Return to Love by Marianne Williamson

This was the refresher I needed to listen to my own sense of self.

Start Stretching Early

Spent some time on plane today and while catching up on my reading I came across the following in a community posting:

Most evidence I’ve seen indicates that 30-40% of the resources on a project not in its early phases using MOST methodologies should be dedicated to rework – something most customers could not swallow if said literally.
This of course is a broad statement.  Factors that seem to affect this (the variables):
1) Flexibility of the architecture – can increase maintenance costs and developer learning curve, but rework can be minimized.  Might be a tradeoff worth considering depending on customer perceptions and requirements.
2) Elegance of architecture – If the architect can foresee changes and design for them, then rework is easier…but this requires a combination of experience and a crystal ball – by no means predictable and can only be measured successfully after the fact.
3) Cross-area development – if developers are constantly switching areas of the project where they are working, this increases the likelihood that they will do something in one area that is not as anticipatory of future changes and perhaps not as elegant as someone that knows the area better.  The tradeoff here is that you reduce the risk exposure to someone leaving, because there is likely someone else ready to step in.
4) Requirement Variability – duh
5) Early Requirement Finalization – duh, but does this ever happen?

The most insightful part of the post was the very first sentence.  The rest of it, was a reasonably insightful explanation of why this conclusion makes sense.  However, I find it refreshing to see someone address this issue so rationally and direct.  Usually, I find myself in the minority on this front.  In this case, it was an accomplished architect in response to a generic question about rework brought on my Agile-type methodologies.

In reality, most of the methodologies that are being pawned off as new are just re-organizations of old schools of thought.  The practices are given new names, sometimes combined for different purposes, but they exist in the same world.  They are subject to the same laws of science and the same volatility of humanity that every other methodology has been subjected to for quite some time.

If you have a reliable architect, following something resembling a clear vision, you will arrive at a destination using a methodology.  If the thing being built is poorly defined or inflexible, if the user volatility is not kept in check, then you will have rework.  Change is just the reality of working at the speed any business runs at these days.

Now that you know that change is emminent, you can fix your mind to adaptability, instead of clutching so tightly to any semblence of stability that happens by.  You are going to have to be flexible, and rewrite something as the vision evolves.  My advice is that it's best to get on with it then, eh?