Search results matching tag 'EMPs (Expensive Management Practices)'

Performance-Based Management and Andy’s Law

andyleonard — Fri, 10 May 2013 13:29:00 GMT

Let’s begin with an assertion:

“People are more important than process.” – Andy, circa 2008

Whenever an enterprise or institution adopts a new process or policy, that policy should serve people and not shackle them. The nicest thing that can be said about a policy that binds people is, “It wasn’t well thought out.” It’s a bad idea, in other words. What’s the logical thing to do when we encounter a bad idea? Reverse it, as quickly as possible. Is it a good idea to hang on to the bad idea because (hypothetically) we’ve paid business consultants lots of money? or someone – even someone we like and respect – may lose face? No. It is not. Those are merely excuses for continuing the bad idea.

I’ve shared my thoughts on Performance-Based Management (PBM) in the past. I believe PBM is a bad idea and I request you take a few minutes to read the post at the link provided. Go ahead, I will wait right here until you’re done. Done? Good.

Performance-Based Management looks great on paper but it just doesn’t work in practice. PBM is based on faulty premises that we will address in a bit, but PBM’s defenders keep claiming “it hasn’t been implemented properly.” Does this excuse sound familiar?

“Why is PBM So Bad, Andy?”

I’m glad you asked!

PBM is an effective way to squelch innovation. It’s not the only way, mind you; but PBM is as effective as non-compete agreements in killing creativity. I wrote about non-compete agreements in The Last Percent,

They [non-compete agreements] effectively shave the last sigma or two from the bell curve of technologist thought and capability. This is precisely the domain where the 100x, 1,000x, and 1,000,000x innovations and inventions dwell.

If you read my earlier post about PBM you see an example of how it kills teamwork – which is a surefire way to limit innovation.

“Why on earth would a technology company implement such a policy, Andy?” That is an excellent question. My answer:

PBM Looks Good on Paper

Unpracticed, PBM appears to solve a number of problems. Performance management is reduced to a bevy of statistics like lines-of-code written or defects closed. PBM claims to recognize an inconvenient truth; all employees are not created equal. Finally, PBM reduces the required skillset of the manager to a spreadsheet jockey; and spreadsheet jockeys are less expensive than experienced managers.

Managing statistics is a lot easier than managing people – especially innovative people. Innovative people are creative, and creative people are notoriously indisposed to authority in any form. Difficult to manage? Indeed, and impossible for some to manage. There are two effective ways to manage innovative individuals:

Gain (or possess) their respect.
Get out of their way.

A spreadsheet jockey is not going to gain the respect of an innovative person. Armed with their spreadsheet and need for metrics collection, the spreadsheet jockey is not going get out of the way. Because of this, PBM is a recipe for disaster for most innovative employees.

I believe the assertion that all employees are not created equal; some are better at their jobs than others. This, I hold, will always be true. But PBM focuses on one end of the less-than-awesome employee issue, putting the onus – and blame – on the employee. I asked a wildly unpopular question of management and HR at the company where a 20-60-20 PBM scheme was inflicted: “Are we hiring the wrong people or are we mismanaging the right people we hire 80% of the time?” I thought that was the right question at the time. I still do.

Fixing PBM

The problem is not that we are doing PBM wrong. The problem is that PBM is wrong. It doesn’t matter how we do it, it will never produce the desired results.

Therefore, PBM must die.

Or at least be neutered. One way to minimize the damage of PBM is to acknowledge there is but one true metric for innovative work: shipping. Creative work is art. And no artist likes to show (measure) the work until it is complete. Once the work is complete it can be measured as done. Why do I advocate a single, holistic metric? Because “shipped” accounts for nuance and intangibles that simply are not measurable. One PBM-neutering tactic is to define this single metric and be done with it. The historical metric is easy as it is a Boolean value: It either shipped or it did not ship. The current status is also simple: It is either done or in development.

“What about measuring how long the project took to ship, Andy?” I’m cool with that as long as you follow some simple rules:

Feed this data into an evidence-based scheduling system
Never use this information against the developer
- In fact, do not even make the developer aware of this information’s existence
- Use this information instead for the developer by adjusting any estimate according to previous evidence

Reporting “shipped” metrics would require a daily email a developer could compose in less than a minute (slightly-sarcastic mini-diatribe about the cost savings of the reduced need for management redacted).

In technology, “shipped” is the only metric that matters. Lines-of-code and defects closed are game-able.

Andy’s Law

I would like to see this abuse of people in the name process come to an end. Performance-Based Management is more than just a bad idea; it’s counter-productive, wastes time, and costs money. Elevating process above people is wrong and bad. Using statistics in this way is math poorly applied. Hence, Andy’s Law:

Statistics may be used to measure anything about people, except people.

:{>

Less Useful Soft Skills

andyleonard — Tue, 23 Oct 2012 11:00:00 GMT

Introduction

This post is the fifty-sixth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

Over a career that spans decades, one encounters useful and “less useful” soft skills in the modern enterprise. I thought I would share a few of the less useful variety:

Free Advice

If someone asks another for advice, that’s a cool compliment. The person asking has seen something that compels them to seek information about how-another-does-or-sees-things. That’s different from someone offering unsolicited advice. Way different. In the first case, the individual asking is open to receive advice. This is often not the case with unsolicited advice.

Anti-anti-pattern: Offer advice when asked.

Retentiveness

Best practices, formatting, case and capitalization are all excellent tools for assisting a developer to represent, support, and facilitate their thoughts and thought processes… until the attempted transfer to another developer. I hope you are seated before you read this next line: Not everyone thinks like you. (I know!) Moreover, not everyone wants to think like you. </shocker>. Others think in ways that facilitate their code development style. Their documentation – or lack thereof – is there (or not) because of their coding style. Some wait until the end of a development to begin code optimization (this is a recommended best practice, by the way) instead of optimizing each code fragment.

Everyone – and I mean everyone – has a preferred method for representing code. I hear you thinking, “But their way doesn’t work for me.” It's. not. supposed. to. work. for. you. It’s supposed to work for them. Different != wrong.

Anti-anti-pattern: Allow others to code in their style. If they observe your coding style and want your advice… see the section on free advice.

Destructive Competition

Wanting to be a better developer is a good thing. Wanting to be better than the developer in the next cubicle is not a good thing. The collective IQ of a team is greater than the collected IQs of the team members. Why? Synergy is the great entropy-buster, spawning positive cycles as team members interact – sans retentiveness. Synergy works best with a dash of humility, and humility facilitates an environment where team members freely seek the advice of each other. Communicating you are the smartest person on the team accomplishes the opposite: striking lines of communication, binding synergy, and destroying the cooperation that would induce a positive cycle. (This is why Performance-Based Management Stinks.)

Anti-anti-pattern: Before acting or speaking ask yourself, “Will this help?” If the answer is not, “Yes, this will help,” don’t act or speak.

:{>

Push The Pebble

andyleonard — Mon, 02 Apr 2012 11:00:00 GMT

Introduction

This post is the fifty-fifth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about starting something.

Today is the First Day…

… of something. Somewhere, someone is starting something that will become big. It will impact lives. It will change things, forever. Somewhere else, someone is improving the thing they started recently. They are tweaking, tinkering, thinking, and doing.

Is either of these people you?

If not, why not?

Dams and Avalanches

Obstacles occur. They are as natural as gravity; they are part of entropy. They block. But they also support. It really depends upon which side of the avalanche or dam you find yourself, and your response to it.

For example, if you are leading a convoy or group of travelers and you need to get from Snowy Point A to Snowy Point B, the banked snow between those points may create a stable bridge that allows you to cross safely and quickly. If you enjoy the lake (or power or fresh water capacity) created by the dam, it is a good thing. But if you find yourself beneath an impending avalanche or in a water-restricted area downstream from the dam, you may feel altogether different about them.

From a physics standpoint, both dams and avalanches represent something called potential. Potential is stored energy. It is ready to be unleashed for good or harm and is being held back by some force or combination of forces.

One Pebble

Do you see metaphors for dams and avalanches in life and work? Is there something that needs to happen? Some energy that could be released for good? How does such energy get released?

Someone, somewhere, starts something.

Avalanches begin when the smallest bit of snow begins moving. Dams fail, beginning with a tiny crack; or with one small pebble becoming dislodged. Once started, all that potential – all that stored energy – begins to work together. If stones and snow were conscious, I doubt the first to move – the starters – would realize what they were starting.

Kick the Pebble

Be a Starter.

“Awesome idea, Andy. But where?” Where are you right now? Start there. Something needs to get done right where you are. Jeremiah Peschka (Blog | @peschkaj | SQLPeople) said it best in the Linchpin session at PASS last October: “If you cannot change where you work, change where you work.” Quit waiting for someone to do something. You do it.

And please hurry. The world is waiting.

:{>

Trick Question

andyleonard — Tue, 27 Mar 2012 11:00:00 GMT

Introduction

This post is the fifty-fourth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about you.

Me?

Yep, you. Two questions:

What is your job title? (<—Not a trick question)
What business are you in? (<—Trick question)

:{>

Managing Confidence

andyleonard — Thu, 22 Mar 2012 11:00:00 GMT

Introduction

This post is the fifty-third part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about inspiring others.

Hot Chicks - Baby chickens beneath a warming lamp…

</NonSubtleSEOPloy>

For those who do not know, we raise chickens that lay eggs – referred to as “laying hens”. Natural attrition has taken our flock of laying hens to 11, plus one rooster. We recently received an order of new chicks (pictured above). We keep them inside for the first couple weeks until they grow enough feathers to withstand outside temperatures. The temperatures in our area this winter have been very mild, so we ordered thirty-three birds earlier than usual. For now, they live in our sunroom in a large box beneath a heat lamp. Hence, hot chicks.

As we approach the time they will be transferred outside, the birds begin to fly. Believe it or not, these chicks can fly a couple feet up, even now. It’s funny to watch because they are a little clumsy and their weight isn’t yet distributed well for flight. Mostly they lack confidence that they can fly well. How do I know? Because the instant one bird flies out, they all do.

Why is that? They see that it is possible. With two cats in the house, we take great care to keep the chicks inside the box. The cats will not bother them while the chicks are in the box, but all bets are off if the birds are running around the house on the floor. I fully expect the cats would give chase and catch them.

Right now, if they knew they could, the chicks are capable of escaping the box. So how do we keep the chicks from realizing they can fly out? We manage their confidence. We have a pretty high box, to begin with. They could fly out, we know this. In fact, one flew to the edge of the former box just the other day – prompting a transfer to an even higher box. Once they know they can make the upper edge, we have to change boxes.

Managing Confidence

This happens on the job.

If you manage people, you are managing their confidence – whether you realize this or not. Your team is leaving work each day either more confident or less confident than when they arrived. Stasis is possible, but not likely. Everyone likes to do a good job. And everyone drops the ball at some time or other.

Managing confidence well means you manage each situation individually. “But that’s a lot more work, Andy.” Yes. Yes it is. One of the reasons a manager is paid more is because the job is supposed to be more work. Establishing and enforcing blanket rules is not only lazy, it treats your employees like they’re in kindergarten. Do you find yourself complaining your employees behave like unmotivated children? That’s a clue. Treating your team poorly diminishes confidence. It’s offensive personally and professionally.

But that’s not your only option as a manager. You can inspire confidence in your team members by treating them with trust and respect. Believe it or not, this is easier to manage than demotivating your employees. It’s less work in the long run. How do you inspire confidence in your team? Treat them with trust and respect.

“Broad and vague terms, Andy…” Yes, so here is a specific example. If you are asked to provide an estimate for something that’s impossible to predict – such as “How long will it take your team to figure out the best and fastest way to accomplish this task?” – your first response as a manager should be along the lines of: “It is impossible to know the answer to that question and, as a result, everything else I say should be considered at something less than 50% confidence.” If someone wants a number, explain why that’s a risk-laden question; and explain the risks. Need help explaining the risks? This should help. Also, read Frederick Brooks’ awesome tome The Mythical Man-Month. Estimating software projects is part science and part art. Stand up for your team in these matters.

Sometime, no matter what you do, you are stuck with an impossible deadline. Years of experience developing software and delivering solutions has taught me that everything is mutable except the delivery date. When faced with those scenarios, I tell my team, “I don’t think this is a fair deadline for this project and I have communicated that fact back up the chain of command. I believe if anyone can bring this in, it’s you. And if you cannot bring this in by the deadline, it simply cannot be done.”

Faking this doesn’t work. It’s not an incantation; it’s a reminder of the confidence I have demonstrated time and time again in the team.

Conclusion

Bolstering the confidence of your team is part of the job of every leader. You want your team members to fly. And if you can encourage the confidence for your team members to succeed, those team members will give you the last percent.

:{>

Q: How Many Calls From Work While on Vacation is Too Many?

andyleonard — Mon, 12 Mar 2012 11:00:00 GMT

A: One.

P.S. This post is the fifty-second part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about how to quickly and efficiently get the employees you need most to begin seeking employment elsewhere.

To Snark or Not to Snark…

andyleonard — Mon, 06 Feb 2012 12:00:00 GMT

Introduction

This post is the fifty-first part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about communication.

On Being Clever

I enjoy listening to a good comedian and reading the works of humorous writers. Life is too short to waste on misery and a hearty laugh is good for the soul. Some humor is educational, thought-provoking and surprising. Some humor, though, can be hurtful.

Some jokes and comments build people up while others tear them down. I understand motivational theories that support “inspiring” people by offending them (you know, so they’ll remember). But many popular and seemingly intuitive management practices simply don’t work – as evidenced in the book Drive by Daniel Pink. While short-term gains are possible, this sort of motivation poisons long-term productivity. That’s not the worst of it. Cleverness – or rather, feeling that one is being clever – is addictive. Some get a thrill out of combining (real or imagined) advantage and snarkiness to achieve a “zinger”.

What Is The Problem I Am Trying To Solve?

The thrill and associated endorphins are understandably pleasant… for the one being snarky.

"As a matter of cosmic history, it has always been easier to destroy, than to create."
-Spock to McCoy, from Star Trek II: The Wrath of Khan

This holds in communications, as well. It is much easier to destroy than create. I am going to take that statement one step further: It is lazier to destroy than create. Inspiring people while not tearing them down is hard. It is way harder than simply throwing some snarky comment in their general direction. It involves something that cannot be manufactured: your engagement. Sure we can multitask, but can we multi-engage?

No.

Engagement is a singleton.

Engagement requires attention. Web marketing people will tell you web advertisements are after our attention. Our attention can be defined many ways. I define it as “the second glance”. If a web marketer or a spammer produces something that draws our eye back to it, they have our attention.

Snarky

Snarkiness will get my attention long enough to accomplish your short-term goal, but it does so at the expense of the long-term. If you are snarky to me, I want to listen to you less in the future. You made your point (congratulations), but you did so at the expense of all future points you wish to make with me.

Is that a win for you?

(Seriously?)

What does that bode for community? How does that fit into the marketing model of the long tail? Putting it into farming terms: Snarkiness is equivalent to eating seeds stored for planting. You are eating today, but you will starve in the future without seeds to plant – which will produce more edible (and planting) seeds.

The Solution

Don’t be snarky. Wil Wheaton (blog | @wilw) puts is succinctly in what has become known as Wheaton’s Law.

Conclusion

Snarkiness may be fun, but it is expensive fun – and the snark foots the bill in terms of influence and reputation. Is it worth it?

Andy

Credibility

andyleonard — Mon, 12 Dec 2011 12:00:00 GMT

Introduction

This post is the fiftieth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about credibility.

The Internal List

I believe everyone has an Internal List of Acceptable Actions (ILAA). I read this in a book about Values-Based Leadership – it may have been this book, I cannot recall. Before I read about the ILAA, I knew it existed. I believe the ILAA is a sorted list, and that the sorting is in order of most-acceptable to least-acceptable. Acceptable to whom? Others, community, or society.

ILAA’s share some characteristics and are a manifestation of our individual consciences. Human conscience is comparable to the Three Laws of Robotics. Actions a human may or may not take are coupled to – are instances of, if you prefer – the rules embedded in our conscience. For example, rescuing a kitten from a life-threatening situation should be near the top of everyone’s ILAA.

Humans Are Not Robots

Our consciences differ. As a result, our individual ILAA’s vary. In most cases, the variance is small and may be insignificant. In some cases, the variance is extreme. In my opinion, ILAA’s are the best metric to determine the values of others. At a minimum, observing the actions of others reveals what they considerable acceptable.

Credibility, Are We There Yet?

This brings us to credibility. Credibility sounds noble. But I consider credibility neutral. “Why, Andy?” I’m glad you asked: I believe a person can be credible and yet hold values detrimental to society, other individuals, or a community. Some I consider credible hold values with which I simply disagree, but they are consistent in their communication and action - and therefore credible. Values are exposed when we observe how people act. I call this listening to what people do.

I believe once a person has demonstrated they are capable of unacceptable behavior – to anyone, for any reason – they have demonstrated they are capable of that same behavior towards you. Why? It’s on their ILAA. They just proved it to you. If you witness a co-worker take something that belongs to another co-worker, they are demonstrating they are capable of stealing from you. If you observe your business partner treat another partner - or a competitor, or a customer, or anyone - unfairly, they are communicating they are capable of treating you unfairly. If you see an organization abuse one person, that organization is explaining “You could be next”. If it is on the ILAA, everyone is a potential target. Remember, this is about what is inside the individual.

Although circumstances may be used to excuse, reason, or justify; circumstances do not apply here. ILAA’s are about capability.

I see credibility as consistency between Values and Actions. When what I say matches what I do, people will judge me credible. When what I say does not align with what I do, people will subtract credibility from their estimation. It would be awesome if it were that simple, but it’s not. There are at least two places that are subject to interpretation:

The interpretation by others of what I say.
The interpretation by others of what I do.

What I Say Is Important

What we say tells us something about what’s inside. In the Court of Public Opinion, everything I say is used for or against me. That’s normal and fair and isn’t going to change. For these reasons, it’s important to consider what I say (or write). Even if I’m very precise (which I am not), what I say and write is subject to interpretation. This is especially true about what I write: I’ve been told I am “direct” in writing. That likely stems from my training as an engineer, but that is merely an excuse. It does not help someone reading my “direct” email to think “maybe Andy is just being an engineer”. And, it leads to confusion in the instances when I am sincerely communicating something unpleasant in a direct manner (it happens).

Things are always lost in translation, regardless of the communication medium. Email is particularly susceptible to this.

I have learned I never have to explain or apologize for things I do not say or write. This has made me less likely to contribute to conversations when I don’t have something positive to add. In matters with which I disagree, I find Gamaliel’s strategy appealing. After Jesus’ death, his followers were still stirring people up. The rulers in Jerusalem had the followers arrested and then told them to stop. But the followers refused, which infuriated the rulers. As the rulers considered what to do next, Gamaliel spoke...

How do I apply this? I believe much in life (and society and community) is organic. I believe things grow – and perish – organically, and that this is part of a natural cycle. To politely apply an organic metaphor, fertilizer will promote growth; but too much fertilizer will kill. Mixing different types of fertilizer can be harmful or deadly to the very things we’re trying to grow, while the correct mixture will support maximum growth. If I can help, I will. If I cannot help, I’m keeping my fertilizer to myself. If there’s a problem, it will self-correct (one way or the other). If the thing is meant to be, it will be. If not, it will fail. All on its own.

I have reached the following conclusion: Sometimes what I intend for help merely distracts from the real issue(s) and thereby prolongs the inevitable organic result.

What I Do Is Important

I noticed a pattern in my behavior this past year: I was doing a lot of things on autopilot. Most of the time this was fine. I have mostly good habits that have served me well over the years. Habits like treating others better than I treat myself, decent priorities, serving people as they crossed my path. That sounds good, but those habits – like the Three Laws of Robotics mentioned earlier – are subject to failure. My habits led me to places I didn’t like at times this past year. One example is found in the apology to which I alluded earlier.

Another example is my priorities. I had the best of intentions but my priorities were out of whack. Looking back, I now realize I had picked the best and most noble paving stones from the center of the road to Hell (which is paved with good intentions). Through engaging in a Bible Study group with some friends and brothers, I believe God revealed this subtle and tragic error in my priorities. Through this same Bible Study, circumstances, and prayer; God has been - and continues - correcting my trajectory.

One result? My word for 2012 is: Intentional. Good habits are good to have, but they are no substitute for thinking. I have been lazy, relegating to good habits matters which require active engagement, thought, and sometimes change. I could write for hours (literally) about the stuff that’s already changed in my life as a result of this reevaluation and active realignment of my priorities but this post is long enough! Some major areas already impacted include:

Communication
Physical fitness
Matters of faith
Finances
Giving (time, money, technical help, social awareness)

There is more to come. Being Intentional is one goal for 2012.

I have learned this past year the importance of forgiveness – of both giving and receiving it. Communities are a social ecology as much as a social economy (more on this later…). If my apology taught me nothing else, it demonstrated to me that our technical community is a forgiving one. Other communities in which I participate share this characteristic.

Conclusion

For me, maintaining credibility is a natural result of choosing to live more transparently. That applies to all areas of my life: family, faith, business, and everything else. I believe credibility works the same for organizations and communities as it does for individuals. In 2012, I will continue to urge the organizations, communities, and individuals I love to practice transparency – and thereby garner more credibility. I will strive to be intentional in all I say and all I do.

:{>

Dashboards

andyleonard — Mon, 05 Dec 2011 12:00:00 GMT

Introduction

This post is the forty-ninth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about dashboards. Dashboards are where data meets decision-makers. The field of data visualization is about this intersection of information and actors. Here, the numbers are translated and communicated in a manner that is clear enough to define action. Decisions are supported by these systems. Business and intelligence meet. The data is right there, represented numerically or graphically or both, waiting to be used.

This post is not about how to accomplish data visualization. This post is about the fact that data should be visualized.

Tufte

Edward Tufte (Blog) is one of the prominent names in the field of data visualization and information design. Well known for his criticism of Microsoft PowerPoint, Tufte has earned a reputation for clarity and insight. He participated in the investigation of the Space Shuttle Columbia disaster. There is a ton of related information here. He has been appointed to presidential panels to ensure integrity in communications. Tufte invented sparklines and is generally considered a data visualization genius.

Data visualization specialists value integrity in communications. At least, the good ones value it.

This Isn’t Hard

Dashboards are elegant. They do not have to be complex. In fact, the most effective data visualizations are intuitive and almost instantly convey the desired information. Simple is good.

A long time ago (back when the years began with the number 1) in a place far, far away; I built a Manufacturing Execution System, or MES. It was called Plant-Wide Webs (catchy, eh?). It was one of the first MES’s to exclusively use a browser for visualization. The idea of PWWs was to convey – at a glance – the state of a manufacturing facility or enterprise. As I mentioned in Performance-Based Management Stinks, the only metrics that count are shipping and delighting customers. I believe that’s true for measuring employee performance. Behind that statement is a principle and it is this: I believe it is possible to isolate or create an effective, single, accurate-enough metric for anything. Is this metric going to communicate everything that’s going on at all levels of your business at a glance? Goodness no. But, I maintain it’s possible to glean way more than 80% of the important truth from a single number (I have more to say about this... later), and that’s what Plant-Wide Webs did. The dashboard? It was a modified stoplight:

I started with an electronic drawing of the facility which I converted to an HTML image map. The map was completely green, yellow, or red. The numbers behind this were not simple, but they were available (via a click or two, max) and condensed into a single metric. And they were near-real-time and immediately recognizable. Back in the day, “near-real-time” meant accurate to about a minute. The plant manager could view their facility’s performance in near-real-time all day. History was provided (of course), and drill-through was supported as well. After all, drilling was as simple as linking; something at which HTML excels. Each click would take the manager to more detail. the first click on the plant image would be a copy of the image split into several shapes, each representing a section of the plant and each reflecting the red-yellow-green status of respective facility sections. And each section was drillable. And so on, and so on; until you reached a screen filled with readings from actual machines – data collected from data acquisition systems or Programmable Logic Controllers (PLCs) or Human-Machine Interface systems (HMIs).

This wasn’t then (and certainly isn’t today) earth-shattering graphics. But it was easy to maintain and scale, fast-rendering, and best of all; simple and clear. It communicated. What did it communicate? The state of the plant? No. The state of the business!

Another Story

Users aren’t stupid. They are your community. If you treat your community like they are stupid, you make more work for yourself. You also communicate that you distrust and disrespect them. Transparency isn’t merely the right thing to do, it is also the smart thing to do.

On my first data professional gig, I was hired to implement and manage the reporting solution. It was a web-based solution and the sales demos must have been impressive. The product actually was impressive as long as you ran it on the correct platform. We ran a ported version on the incorrect platform. </SadFace></WithASmallTear>. Back in those days I could hold my own as a web developer. The short version of a long story is: I fixed the ported code. I was done when the manager decided to move the current SQL Server person to another position. Since I was the only other person with the words “SQL” and “Server” near each other on my resume, I got the gig. Now mind you, I thought I could do the job. When my manager asked me if I could do it I told him “Yes. How hard can it be to tell developers ‘No’?” </CaptainSnarkyIWas>. I learned a lot during that first real database person position.

I did a few things right, though. One of them was to trust my community. We started with a pilot of ten “power users”. They were all internal, part of the same company as us. But the next step was to expand to something like eighty users, and not all of them worked for us. So they didn’t have access to all the information available to the original group.

It sounds like a simple thing. Here’s why it wasn’t:

In ETL (Extract, Transform, and Load) operations there is this thing called Latency (an engineering idea) that is tightly coupled and indirectly proportional to another thing called Throughput. The more ___ you can shove through a pipe, the less latency you experience. Back then, we were loading a ton of data, relatively speaking. It took days to load a couple tables in our data warehouse. Since we didn’t want to wait around the clock, I found an old spreadsheet I created to do predictive analytics, and we would sample the current number of rows in the destination table every now and then along with the time, and then do some math, and then do some more math, and then we’d have a science-backed wild guess about when the table would contain all the rows from the source. (The funny part of this story? I developed that spreadsheet while working as a 3rd-shift electrician in a hardware plant to determine how long a large tank would take to fill. Fluid levels, data, it doesn’t matter – the math is the same. James Maxwell would be proud.)

That inspired another idea: I could build a web page to display the latency metadata used as the source in part of the calculations. It was a fantastic internal tool. That inspired another idea: Why keep it internal? Most of the calls I was fielding were from users outside the company who had no idea why their report numbers were changing with each refresh. Everyone inside knew when there was an issue with the overnight batch processing that increased latency. But not those outside. So I placed a link to the latency page on the website and published the latency data with our next release.

I almost got fired.

My boss considered that data proprietary because it basically showed when we were not compliant with our SLA. I get that (now, I didn’t back then, but I do now). It never occurred to me that we should withhold information the users needed to make informed decisions about the validity of the information we provided. It still doesn’t occur to me. Transparency stopped my phone from ringing, allowing me to concentrate on more pressing (and valuable) matters. I probably would have been fired if the bosses of the external users hadn’t called my boss’s boss to tell her what an awesome idea that was. Just about the time my boss was ready to chew me out for releasing “proprietary performance and SLA data” he got a call from his boss, and she chewed him out for not letting her know about this cool new initiative that was saving our customers time and increasing the value of our data and service to them.

Elegant != Pretty

I tell every student that attends my From Zero To SSIS! class: “Anyone can build SSIS packages that work. I expect your SSIS packages to also be pretty.” But I leave them with this caveat: “If you have to choose between pretty and functional, always choose functional.” The same goes for dashboards. If you are afforded the time to delight the customer, do so. If not, opt for “working” over “pretty” every time. Make it as pretty and fast as you possibly can, right after you get it working. Remember:

Deliver quality late, no one remembers.
Deliver junk on time, no one forgets. – Andy, circa 2004

I’ve never had a customer or user come back to me after delivering quality late and say “Sure, Andy. This works well and all, but you were two days late.” They simply do not remember that it was late if it does what they want. But come in early and under budget with bugs? You will not hear the end of it.

Communicate

A dashboard is simply a communication medium. It translates data into actionable information. It’s that simple. If your dashboard does amazing things but sacrifices any portion of this vital function, then your dashboard stinks. Get this part right. Communicate the state of the business quickly and accurately. Provide multiple levels (grains) of information. Trust and respect your community, for they can make your job easier or more difficult.

Conclusion

Dashboard development and implementation is more art than science. Treat it as such.

:{>

Performance-Based Management Stinks

andyleonard — Thu, 03 Nov 2011 11:00:00 GMT

Introduction

This post is the forty-eighth part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.

This post is about Performance-Based Management (PBM).

Almost…

In Mere Christianity, C. S. Lewis refutes an argument with the following statement:

It has every amiable quality except that of being useful.

I feel the same way about PBM.

I am a metrics person. I thrive – intellectually, emotionally, and economically – on business intelligence and KPIs and dashboards. I love data mining and predictive analytics. Measurement, analysis… this all appeals to my engineer’s nature and “instrumentation-eer‘s” heart. When it comes to Performance-Based Management, you’d expect me to be all in. And I was, almost.

There I Was…

… sitting in the cat-bird seat. We were a team of five charged with expanding a successful data warehouse. We had a person who wrote special one-off applications for data mining, an awesome business analyst, a great report-writer, a guy who knew the source system like the back of his hand, and me – the SQL Server database guy. The company had implemented a 20-60-20 PBM scheme after someone who’s title began with the letter C read a book and thought: “Why are we wasting all this time thinking and leading and managing when we could just lump people into one of three buckets and be done with it! Think of all the time we could spend reading more cool books!” Ok, I’m not sure why it was implemented; that’s just my theory. But I digress…

With five people on the team the math worked out perfectly. We would have one “top 20” person, one “bottom 20” person, and three “middle 60” people. Awesome. Except how do we determine who goes where? By luck of the draw, I happened to solve the big-problem-du-jour the week before the managers were to submit their suggestions for rankings. I won the PBM lottery, as it were. The person who had been in my position earlier, and who had contributed to my success substantially, was ranked last. The other three were lumped into the middle 60.

Here’s my first question: If we are a team and we each have vastly different roles and we are each good at our job, how do you determine who outperforms the others? PBM has a smarmy answer for this scenario, and that answer has every amiable quality except that of being useful.

What really happens in this scenario? It turns out that it takes a village to build and maintain a successful and useful data warehouse project. In other words, a team. When everyone contributes to the success of the project, a positive spiral is created. Everyone realizes they are their brother’s keeper; that the success of all hangs on the success of each. What’s more, teamwork is easier. It requires real effort to produce anything of value single-handed.

But wait there’s more! Because more eyes are on the work, quality improves. The quality percentage for a useless data warehouse – the ratio of good data / bad data – is a surprisingly high number. This is due to how the data is used, mostly in aggregation. Constraint Theory teaches us that losses accumulate, gains don’t. In a data warehouse project, the impact of incorrect data or the incorrect application of data is exponential. If you don’t believe this before your first data warehouse project, I bet you will afterwards. It turns out this “friendly competition” kills teamwork faster than anything else. Good people feel less motivated to help because they are punished for the success of others.

Punished? How?

I’m glad you asked. In the version of PBM through which our team suffered, the top 20 person got everything they wanted. The bottom 20 person was basically ignored until they quit or were fired. The middle 60 were alternately tolerated and encouraged to be more like the top 20 person. But we were all good at our jobs!

That didn’t matter. Only the buckets mattered.

And this is one of the reasons PBM stinks: It kills teamwork.

My Question

Upon learning the mechanics of PBM, I asked the following question: “Are we hiring the wrong people or are we mismanaging the right people we hire 80% of the time?” I think that is the right question.

Conclusion

I have witnessed many peers subjected to Performance-Based Management. To a fault, everyone suffers. PBM is an application of the manufacturing mindset to modern business and it fails to recognize important facets of creating technology. The goal of PBM is equally noble and unachievable.

It. doesn’t. work.

The only metrics that count are shipping and delighting consumers. Good luck breaking those metrics into measurable steps. You can waste time with PBM or anything else that is-not-creating-art. It’s your call.

:{>