Search results matching tags 'EMPs (Expensive Management Practices)' and 'Leadership'

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.

:{>

Outlasting Outrageous Opposition

andyleonard — Wed, 27 Jul 2011 11:00:00 GMT

Introduction

This post is the forty-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 responding to outrageous opposition.

Opposition Happens

As I stated in Love Your Enemies, opposition is a clue. Does that mean all opposition is good or can be put to good use? Nope. Some of it is troll-ish noise. How can you tell the difference between someone who is competing with you and someone capable of dangerous and destructive behavior and actions against you or your enterprise? Hindsight is unfortunately the only definite answer. I wish there were better ways to discern between those who will merely oppose your art or work and those who will purposefully engage in activities designed to impede or destroy it.

Hints

I have noticed the following about individuals who behave destructively:

You are probably not their first. There’s a good chance an individual bent on destructive activities has behaved this way in the past. In an age of ever-increasing transparency, these folks leave a trail.
Lord knows what motivates them to behave in this manner but they are, thankfully, a tiny minority. This makes identifying them easier – especially in social media circles. Start by identifying the beginning of destructive behavior and then see who became emotionally charged just prior. This represents a sample of potential culprits. Repeated and spread across several incidents, an ever-narrowing pattern emerges. In many social media communities, two incidents is often enough to isolate an individual attempting anonymous activity.
Their destructive efforts usually come to naught. Visibility of their efforts is their greatest ally and their Achilles heel. Become too visible and they’re exposed; not visible enough and no one notices. Destructive behavior is the Ebola virus of social media communities, damaging the carriers before more serious harm can be done.

Conclusion

So how does one respond effectively to trolls? Ignore them. Again, we don’t know the motivation; but anyone who’s been around a five-year-old-who-isn’t-getting-their-way understands the goal is attention. If they don’t get attention from you, they will move on.

:{>

The Last Percent

andyleonard — Tue, 05 Jul 2011 11:00:00 GMT

Introduction

This post is the forty-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 the removing obstacles to performance (in people).

People Are Good

I believe people want to perform well – in life, on the job, in business and personal relationships. I think this is the natural state of most people, that people are basically good. There are some exceptions, obviously, and I think society has mechanisms for correcting deviations. And all people deviate from time to time through habit, error, or poor choices. But essentially, people want to do good and be good.

Daniel Pink writes about the work of Edward Deci discovering and measuring individual motivations in the book Drive; Clay Shirky writes about the same topic in is book Cognitive Surplus. Some of Deci’s work measures the effect of removing love from work. It does not, as popularly misinterpreted in business schools around the world, establish a link between stagnant pay and consistent performance.

Blocking Requests

I think leaders often get in the way of this inherent motivation in people to do good. Most of the time, this is unintentional. Sometimes it isn’t unintentional. There are people out there who derive pleasure from manipulating others. Some requests made by leadership are reasonable and must simply be executed. This is the use case for military orders delivered during combat. But most of us aren’t in physical combat (God bless those who are, I pray for them). The closest we come to this scenario is agile business or development environments where fast action and response is critical to success. The leader may have access to more information than is available to those she leads. In these scenarios, communication is vital. But even more vital is a history of trust and respect. If the leader is not the type of person to abuse their authority merely to enjoy the reactions of others, the leader is more apt to obtain the trust and respect of those they lead. Professionals want to know why they’re being asked to do something because they want to do a good job. If they know why, they will be able to adapt to and overcome obstacles – perhaps reducing the time or adding success to the achievement.

Holding up a hoop and expecting others to jump through? Ordering “Jump!” to hear others respond “How high?” These are simply blocking requests.

What do I mean by blocking requests? The human brain is an awesome processor. I recently read an estimate that the total computational power on the planet at this time is comparable to that of the computing power of a single human brain. While that represents the astounding amount of capacity required by conscious thought, it reflects the fact that the human mind’s abilities are also finite. People can (and do) use their minds to create amazing inventions and philosophies, to conceive art and discover science; but the mind cannot produce more mind. At least not in 2011.

Conscious attention is a subset of the working cognitive brain power available. Blocking requests – holding up hoops or ordering others to jump – consume cycles better spent on other tasks.

An Example

One example comes from a past conversation with a gifted technologist. He is well-known in his field as someone who’s created elegant solutions to complex problems. He’s currently employed by a company that believes anything he invents during his tenure with the company – whether on the clock or off – belongs to the company. It gets worse: As a condition of employment, he was required to sign a document to this effect. The result? He’s stopped innovating outside of work. This has impacted his performance on the job, as well as his opinion of the company for which he works. He longs for trust and respect, he wants to love his job. But this agreement effectively limits the cycles he desires to put into work outside of company employment, which in turn undercuts his continuing education, which in turn limits his effectiveness at work, which in turn reduces his performance, which in turn depresses him. It’s an engine of loss.

Agility

I formally encountered Agile Software Development in the late 1990’s via a variation of Test-Driven Development known as Fail-First Development. The idea is to begin by writing a test, execute the test (it should always fail first), then add code until the test succeeds. The methodology helps young engineers formulate their thinking, prioritizing the steps to achieve a working system. I loved it because I wrote a lot of code that failed the first time I executed it. TDD was a natural fit for me! (It still is…)

The elegance of Agile Software Development lies in its truth. First and foremost, Agile acknowledges some uncomfortable truths about software development. Next, Agile incorporates those tenets into a framework that produces better software. By recognizing the physics involved in software creation, Agile enables developers to see beyond the box and perform better.

Previous software methodologies grew from manufacturing and construction thinking. And it worked. For a while. It worked because software implementations were performed on relatively crude machines (which were themselves subject to the manufacturing / construction paradigms). When true abstraction began, gaps in the manufacturing / construction thinking began appearing. It’s not possible to build a skyscraper starting with the 42nd floor; but it’s commonplace in 2011 to model the presentation layer in software development early in the project. And by “model”, I mean build quickly using a tool that allows you to demonstrate intent and later convert into production code. The model is, effectively, the 42nd floor; and it’s built early to gather feedback from the customer and users. Attempting to apply manufacturing and construction methodologies to modern software development is increasingly difficult. It no longer maps. It’s no longer accurate. It’s no longer true.

In a nutshell, Agile doesn’t lie about software development.

Comparisons…

In the current market, talented technologists move from venture to venture every couple years. While they’re at Venture A, they learn stuff that inevitably finds its way into their work at Venture B; stuff that inevitably finds its way into their work at Venture C… And so the cycle repeats. Companies trying to protect intellectual property pay lawyers to draft long contractual documents to ostensibly preclude industrial espionage; but they also – conveniently – stifle competition and innovation, as in the case of the gifted technologist I mentioned earlier. Non-compete documentation fails almost every time it comes to trial, because many of the cases come down to an individual’s ability to earn a living.

(== Summary == Standard deviation diagram, based an original graph by Jeremy Kemp, in 2005-02-09 [http://pbeirne.com/Programming/gaussian.ps]. This figure was started in R using: <pre> x <- seq(-4,4,.1) plot(x,dnorm(x),type)

People grow. Technologists learn stuff. They “play”. It’s in their nature to do so. But non-compete agreements stifle their creativity and are not enforceable. They leverage the fear of prosecution and the integrity of the individual to abuse power and, ultimately, present a barrier to excellence. They 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.

What a sad state of affairs.

One Solution

What would happen if businesses adopted a solution that recognized the conditions of modern economics for gifted technologists? What if, instead of punishing the technologist for learning as she grows from engagement to engagement, we defined business practices that accept or even encourage the nomadic nature of the technology market? What if we stopped lying? What would happen if we embraced the truth?

What would this look like in practice?

No Non-Compete Agreements

For one; unenforceable, innovation-killing non-compete agreements would go the way of the horse and buggy – quaint, nostalgic, but not useful in modern practice.

Ownership Agreements

In the place of non-competes, imagine ownership agreements that express that the ~~serf~~ inventor of an idea owns the idea (I know! Crazy, isn’t it?) and that this extends to works derived from the current employer’s intellectual property. Business leaders and MBAs are of two minds when it comes to derivative works. On one hand, they don’t mind it one bit when they derive something from another patented process and profit from it. On the other hand, they expressly forbid as many others as possible from doing the same thing to their inventions (see hypocritical).

Once the technologist is free to innovate, they can produce unimaginably awesome technology. And again, most technologists are good people who want to do a good job; so they’re more than willing to share the spoils with the employer who allowed (or facilitated, even!) their success in innovation (Note: I’m speaking of a minority stake). This is due in large part to the thrill of producing experienced by every technologist I know. Once this thrill is experienced, the technologist wants to do it again. And again. This stands in stark contrast to the gambling nature of the modern MBA who’s sole purpose in life is to score big on “one huge innovation” and then retire to Tahiti, consequences to plebeians roundly ignored.

Should the MBA / business own a (minority) stake in the derivative work? Once the non-compete thinking is abolished, such a suggestion becomes plausible. It’s amazing the possibilities that emerge once the threat of starving and/or bankruptcy are removed from the equation.

Conclusion

This post was inspired from two sources: conversations with my business partner Brian Moran (@briancmoran) and a comment in an anecdote from The Art of Possibility, recommended here by my friend and brother K. Brian Kelley (Blog | @kbriankelley | SQLPeople). Brian Moran and I are intentionally and deliberately defining a philosophy for our new business. We believe it is important and worth the effort.

The comment from The Art of Possibility is from an anecdote on pages 37 and 38 of the paperback edition. It’s about an orchestral conductor’s response to a musician who was disengaged from the piece of music at hand. After he found a way to engage her (he listened to her complaint – again, crazy idea) he had this comment:

"When I had been viewing her as an unimportant casualty, I had to pretend it did not matter that for some reason she was not engaged. Meanwhile, I wasted energy both watching and ignoring her."

Wow. Think of all the energy wasted in companies today. Think of all the energy wasted in communities viewing members as unimportant casualties (vocal minorities).

The conductor's final conclusion after communicating with this individual?

"The lesson I learned is that the player who looks least engaged may be the most committed member of the group."

Are we smarter than this? Can we find a better way?

:{>

Elegant Events

andyleonard — Mon, 28 Mar 2011 11:00:00 GMT

This post is cross-posted at the new SQLPeople Wordpress blog (in beta as I type this).

Introduction

I debated including this post on elegant events in my series about managing technical teams and the software business. I find a lot of what I've learned in the community maps into both that series and good management practices (the opposite of Expensive Management Practices [EMPs]). Ultimately I decided to let it stand on its own.

Ahead of the Curve

I started my post entitled SQLUniversity Professional Development Week: Learning To Fly with a joke:

Clem and Jim Bob were out hunting the other day in the woods south of Farmville. As they crossed a ridge, they came upon a big ol' Momma Bear and her cub. The larger bear immediately started towards them. Jim Bob took off running as fast as he could. He stopped when he realized Clem wasn't with him. And when he saw Clem reaching into his pack, Jim Bob was incredulous: "Hurry Clem! That bar's comin' fast! You need to out run 'er!" Clem kicked off his boots and pulled running shoes out of his pack. "No Jim Bob, I just have to outrun you!"

In Timing is Everything I wrote:

See those folks ahead of you on the path? They're no different than you. You're no different from them. They started on the path earlier - that's all.

These describe where all of us are, compared to all the rest of us. Are any of us better? I don't think so. We all have gifts. We all started at some point. Everyone knows something most others don't know. Everyone needs to learn something. No one knows it all. That's the main reason we're...

Stronger Together

When we work together as a community, we're stronger than the sum of our parts. We're able to accomplish more as a community than we'd ever be able to accomplish as disconnected individuals. Community does more than merely connect us:

Community makes us stronger.

One of the coolest parts of the SQL Server Community are the events. Most SQL Server Community events are...

Elegant Events

Elegant events share some characteristics. They are democratic, cyclical, and responsive.

Democratic

Democracy implies voting, but I humbly submit to you that this need not be the case. Voting is a great way to employ democracy, but democracy has as much to do with flatness and input to leadership. I'm going to throw out a pretty radical idea here: I don't think you can do community without democracy, and I don't think you can do democracy without community. Democracy without community is disjointed and extremely messy; it's chaotic; it's mob rule. Left to its own devices, community-free democracy evolves (or devolves, depending on your perspective and goals) into either anarchy or community. When people are involved, there are no other options. Community without democracy is a hierarchy. Hierarchies are fine structures... for data, not for people. It follows the Nascar model (I enjoy Nascar... well, most of it. There's no place for race tracks with right turns in my opinion, but we'll save that discussion for later...). The Nascar race model is: 43 cars start a race and 1 car wins.

That's awesome - for the winner. But let's do the math: 43 entrants - 1 winner == 42 losers. Simply put: Communities without democracy don't scale. How do you know if you're a community missing democracy (or enough democracy)? It's easy - you too can do the math. Ask yourself this simple question:

Are you producing more losers than winners?

If the answer is "Yes," I'll give you one guesses about the direction and future of your community. Your community is scaling all right, but in the wrong direction. You're growing dissatisfaction. You're increasing angst. You're inspiring your members to seek out and support other communities. And let's face it: If your community doesn't have people, what does it have?

Cyclical

Elegant events engage positive spirals. Good begets good, trust begets trust, respect begets respect. Get all three working in tandem and you have a great positive cycle going. Here's a little secret about a great positive cycle: People are the engine.

If you're attempting a non-democratic community, you're fueling a negative cycle. If the Theory of Constraints taught us anything, it taught us the universe is biased: Losses accumulate, gains don't. Physics teaches us this too. It's called entropy. If your non-democratic community is producing 42 losers for each winner, you're stacking up losses at a decent clip. Since they accumulate, the negative spiral operates on a different dynamic than positive spirals. Negative spirals are... sedentary and sticky. They require very little to remain - they're anti-momentum for a community.

All communities interact with cycles. The question is: Are your cycles positive or negative? One way to achieve more positive cycles is to be more...

Responsive

Responsive communities not only hear their members, they act on what they hear. Vibrant communities act this way by default. In other words, they don't occasionally do something responsive - one thing for every forty-two times they aren't responsive - and then point to that forty-two times and say "See? We care!"

It's really all about which way the knee jerks.

Conclusion

Elegant Events are the heartbeats of vibrant communities.

:{>

Passion

andyleonard — Mon, 06 Sep 2010 11:00:00 GMT

Introduction

This post is the twenty-fourth part of a ramble-rant about the software business. The current posts in this series are:

This post is about passion.

Love or Hate

Love and hate are not scalars; they're vectors. Hate is love moving in the opposite direction. The opposite of love is not hate, it's indifference. Indifference is also a vector - but its magnitude is zero. It's not going anywhere. If you're managing a team of developers, you don't want indifference or apathy; you want them engaged.

Engaged developers are passionate about their work. They have a sense of ownership - perhaps an over-developed sense of ownership. They work like crazy to deliver. And they take pride in their work. This all sounds great because, well, it is all great. But the way developers communicate their passion varies.

Most are protective of their code - to a fault. This means they will turn on you in a heartbeat if you criticize their baby. Some react poorly. Others behave badly. It happens. You can write them off as poor communicators if you want, but this would be a mistake. Why? We admire the gumption of the developer when they're busy delivering; this is yet another expression of that same passion. It's a package deal.

In Community...

The same can be said about members of a community or tribe. In two years of managing teams, I've learned a lot of concepts about tribes apply in business. I've also learned the inverse is not true - things that work in business often translate poorly to community.

There's some fascinating thinking about why. I've been reading some interesting books lately. I like to read several books on a subject at once - it's sort of a mental mixed drink of ideas (I'm weird like that, but if you read this blog you already know I'm weird...). I've been reading Tribes, Drive, The Cathedral and the Bazaar, Thinking Strategically: The Competitive Edge in Business, Politics, and Everyday Life, and Cognitive Surplus. More than one of these books offers interpretations of the work of Edward L. Deci that supports incentive theories regarding intrinsic / extrinsic motivations.

One interesting tidbit about the transition from intrinsic to extrinsic motivations is:

It's a One-Way Trip

From Self-determination theory: Basic needs and intrinsic motivation...

Deci (1971)^[26] found that offering people extrinsic rewards for behaviour that is intrinsically motivated undermined the intrinsic motivation as they grow less interested in it. Initially intrinsically motivated behaviour becomes controlled by external rewards, which undermines their autonomy.

In other words, when external motivations replace internal, the activity / interest / motivation decreases.

Salary?

A lot of people will tell you this means salary doesn't matter. Ironically, those same people are likely attempting to increase their bonus or salary by controlling the salaries of others. <sarcasm> It's a stretch, but I consider this a conflict of interest. </sarcasm> Seriously, I consider it proof of just the opposite - since salary is indeed motivating these people. Salary isn't the point (not here at least. Please see my post on Definition of a Great Team for more on salary's role). Salary is a distraction in a conversation about passion and motivation. Like oxygen, salary isn't the issue so long as you're getting enough.

It's about passion. There's room for passion in developer teams. There's actually a dearth of passion because developers have been told to temper theirs. What have we done? What were we thinking? Oh that's right - it's more important to play nice than... what? Compete successfully? Deliver? Remember: it's a package deal.

Conclusion

I see companies and communities struggling with passion. I see some figuring it out - some of these are learning the hard way. Kill the passion and everyone feels good about their contribution... until the company or community folds, that is. Tolerate - no - embrace the passion and everyone feels good about results and delivering and succeeding.

It's the difference between playing a good game and winning a good game. Both are important and you can choose to feel good about either.

I choose to feel good about delivering.

:{> Andy

Ringing

andyleonard — Mon, 09 Aug 2010 11:00:00 GMT

Introduction

This post is the twenty-third part of a ramble-rant about the software business. The current posts in this series are:

This post is about natural development cycles.

Ringing

"Ringing" describes the curve of a waveform that occurs naturally. It's called "ringing" because striking a bell is one of the natural places this curve appears. I see this curve in software projects.

Code churn
Bug rate and severity
Developer enthusiasm

Code Churn

Code Churn is a generic attempt to measure the stability of software under development. It improves upon the earlier Lines-of-Code metric by measuring line of code added, deleted, and edited. One of my more productive days as a developer resulted in removing 90% of the lines of code. My LOC metric for that day was "-1800" but the software (code-behind a web page pre-.Net, before code-behind was automated) was 10 times faster.

At the beginning of a project, code churn will spike and bottom-out as teh development team figures out the best approach to solving complex challenges. One way developers manage this is to sketch out the workflow and identify the "difficult" stuff. Let's face it: If you've been designing solutions for any length of time you have solved some common problems before. You don't need to reinvent the wheel, you can simply utilize the same design pattern.

Once the difficult items are identified, it's common to start by developing those pieces of code. Solving the big mysteries first allows you to knock out a proof-of-concept and will drive the more familiar portion of the design. It's not uncommon to develop several proofs-of-concept applications to test various approaches to the solution and even different tools. This makes for lots of code additions, deletions, and modifications. As development time nears the release date, code churn stabilizes to a predictable norm.

Bug Rate and Severity

When testing begins, you'll see lots of bugs reported and then fixed, then almost as many bugs reported and then fixed. The curve will ebb and flow, it's as natural as ocean waves washing ashore. In general (and all generalizations are false), the number and severity of bugs will decrease over time. they will become "fewer and farther between." Stability ensues as the ringing subsides.

Developer Enthusiasm

Developers need a challenge. Stop challenging them and they get bored. They respond to challenges differently - most start new projects enthusiastically, followed by stark realization of the scope of work vs. the timeline - which dimishes enthusiasm. As the project progresses, mysteries are revealed and problems solved. Gradually, the unknowns dissipate. For developers, emotions ring at the beginning of the project until the unknowns are resolved.

Conclusion

Ringing is normal. It's tempting to react to the troughs - or even the crests. Relaxing when things look good can be just as damaging as creating drama when things look bad. A steady hand is required to manage ringing. Realize it's normal, and be a normalizing influence.

:{>

Software is Organic, Part 2

andyleonard — Wed, 07 Jul 2010 11:00:00 GMT

Introduction

This post is the twenty-second part of a ramble-rant about the software business. The current posts in this series are:

This post is about organic software management.

Organic Software Management

The beauty of organic software management is the software and teams perform as they should. Can you force a management style onto a team? Yes. Does it produce? Sometimes, but rarely as good or as much as organic management. Why? Because people self-organize. And they do so instinctively; organically even.

Geeks are people too. Whenever I think about how geeks socialize I am reminded of a quote from the movie I, Robot (not sure if it was in the book, and I find the robot series from Asimov very inspiring): "Why is it that when robots are stored in an empty space, they will group together, rather than stand alone?"

Many of you know this already: Our family raises chickens on our small farm in Farmville Virginia (I am not making up the name of the town, I promise). These are egg birds, not for meat. We also have a small garden. We derive immense satisfaction from growing our own food. It's amazing how versatile nature really is. If you get a few things right, you can do almost anything you want to a garden and still get vegetables and fruit. If you don't do those few things right - and all of them, mind you - you will get little if anything from your garden.

The first key is creating the right conditions. The second key is planting the right stuff at the right time. The third key is taking care of the garden. Our garden is my model for using the word "organic."

So how does organic software management apply to teams?

Are the conditions conducive to produce the desired outcome?
Are you introducing the right stuff at the right time?
Are you taking care of the team / project?

1. Conducive Conditions

When you think of the conditions required to produce quality software, what do you think of? I think of a comfortable and quiet workspace, modern equipment, and reasonable management.

Some folks can code away in a noisy, busy environment - some have to. Others cannot. I'm one who needs quiet. If I'm not in a quiet environment, I create a controlled noisy environment through the magic of my Zune. Nothing breaks my heart more than seeing developers tasked with creating tomorrow's applications on yesterday's equipment and software development platforms. The people who hired those developers must think they're super-awesome-coders... I bet they're paying them as if they're super-awesome... Probably not. Probably someone is "saving money". My favorite anecdote about saving money involves toilet paper - it keeps the crowd on the edge of their seats. I'll blog about saving money later.

2. Stuff and Timing

This is a broad topic. When it comes to managing a team of developers it involves lots of communication. Good people will draw more work. This will start a cycle that ends with intervention from management or the good developer. Usually the good developer manages it by quitting, so it behooves the manager to get involved before this happens.

Good developers need breaks. Most (but not all) good developers love learning new stuff. Training is a win-win for these folks. They get a break, and learn something new that can help the team and organization.

Also, developer teams require steering. It's not suicide knob steering here; think tiller on a large boat. Gentle guidance, not wild thrashing. And definitely not too much - over-steering can get you into trouble faster than anything else (especially if you're on a slippery surface). Leadership is the answer and I prefer the follow-me style of leadership. A lot of this overlaps with...

3. Taking Care of the Team

In our garden, we do things to keep stuff we don't want out. We weed, we apply as little pseticide as we can (erring on the side of losing plants rather than over-treating), and we shoot at the neighbors we catch stealing stuff. Ok, I made that last part up. Our neighbors are welcome to anything they want from our garden. We only shoot at people we don't know (or readily recognize) - and even then we fire a warning shot first.

Everyone is not a good fit for every team. Taking care of the team sometimes means letting good people leave simply because they're not a good fit for the curent operation. It's weeding. Other times people outgrow the team and there's no place inside the organization for them. Occasionally folks blossom and take root in other sections of the organization. That's transplanting.

Conclusion

I'm sure the organic analogy breaks down at some point. I see these patterns all over organizations. Fighting them seems counter-productive.

:{>

Diversity

andyleonard — Thu, 01 Jul 2010 11:00:00 GMT

Introduction

This post is the twenty-first part of a ramble-rant about the software business. The current posts in this series are:

This post is about the power of diversity.

GroupThink

There are at least two ways of looking at anything. For example, you can say groupthink has altered the course of history. That sounds positive. You can also say groupthink is responsible for atrocities against humanity that scar history. Not so positive. Both are accurate, one is spin.

No one wakes up in the morning and says "I think I'll suspend logic today and just blindly agree to whatever anyone suggests." At least I hope no one does that. Groupthink takes time and, like other forms of mold and decay, is an organic process.

Combating Groupthink

If you get a bunch of people who have similarly trained in solving problems in one domain, why are people shocked when groupthink occurs? Diversity is the key to keeping groupthink at bay. I'm not talking about social diversity, I'm talking about diversity of thought.

For example, if you put a gaggle of MBAs in a room and present a case study (MBAs are uniquely qualified to deal with case studies because this is the chief mechanism used to train them) they will reach a conclusion. Odds are they will employ the tools of their trade and analyze the case study from top to bottom. There will not be uniformity, but there will be consensus. In some instances, consensus is exactly what you want.

In other instances, you want more ideas on the board and more approaches than what they teach in business school. My point? In every project, there's at least one place where a less popular (or harder to sell) option is a - or even the - differentiator.

Convenience...

...is often the enemy of diversity. We look for people with certain skills to bild our teams. We search for folks with similar backgrounds - sometimes unconsciously. We want to work for a company of like-minded individuals. It's... well, it's comfortable.

But will we succeed if we're trying innovate in this way? Will we grow if we join a group of people who all think like we already do?

This is one reason I love the SQL Server community. We have lots of diversity (trust me). We have DBAs with experience in multiple platforms and those who've never executed a query outside of SQL Server. We have performance people, high-availability people, business intelligence people, and storage people - to name just a few. These are just our differences within the domain of SQL Server! This is one of our strengths as a community, in my opinion.

Another strength is mutual trust and respect. And Jagermeister.

Conclusion

Diversity of thought is a good thing. It's not always easy to manage, but diversity ultimately produces better results.

:{>