Making People Make Decisions Is Risky Business

When you're designing a system or database, you can't have ambiguity. Things either fit in the database / model or they don't. You can backlog or table things that don't make sense but you as the system engineer have to know what's going on. You have to listen to the users and customers but you can't make concessions that break the whole system. In this way you have to be somewhat forceful with people sometimes to "make them" make decisions.

How is this possible or why is this possible? I don't know. Force of will? I believe in my consulting work some people really don't like me and really don't get me; they don't know what I'm trying to do or why. They may see me as inflexible. I can understand that. But I'm building a system and it has rules. I only know what I do and not know and am not willing to integrate concepts and ideas that cloud my world view. Sorry if this is selfish, strange, or anti-social but this is the way it is.

Do you have different ideas of how to design collaborative systems? My goal, in the end, is that the systems are collaborative and software based; that Eric Veal is not a part of the system, rather a facilitator to that which is OUR system. I am just a facilitator. Good processes will make the system go, not Eric Veal.

I’ll Learn It at Some Point but Don’t Need to Now

In database programming, I frequently use "views" to solve problems. Views have limitations, especially when you use "SELECT *". If the underlying schema is refreshed—at least in SQL Server—the data gets out of whack. I really want to figure out a better way of doing this; and I'm sure I will at some point…but I don't have time right now. Since I know how to make this method work (with all of its warts) I am okay to operate using this method because I know what I don't know.

Hopefully soon I'll learn how to work around this problem; either by automatically refreshing my views or by learning more about how to use SQL CTE's (Common Table Expressions).

“Give Him a Chance to Think”

I want people to think of me in this way. Not revered, necessarily, but respected; thought of as someone who requires time to think and when he is provided it, he comes up with good ideas. Sometimes the idea will come immediately, as part of conversation, and sometimes it will come hours, days, or years later. This is the type of "mental space" I would like people to provide me. It will be work for me to get to the place where I can expect and get it.

Do What Demonstrates the Highest Possible Value and Be Prepared to Tell a Story About It

Requirements and fixed plans are a tricky breed. When you're on deadlines and things are either slipping or getting behind or, say, you're developing some technical debt from which you can't currently escape, go ahead and start thinking of what you can do NOW that will add the most value to the system OVERALL. Always think of the overall, even when you're in the weeds. My project for example has about 8 items due this week and we are scrambling to do as much as we can. Throughout the day we re-plan and reprioritized based on where we're at and where we have to go. We always keep in mind "What's the story", meaning do we have a good story to tell management or the customer about what we're doing. We don't want to be careless or wasteful so we think of what's the best next thing to to and we do it. After we're done with it we repriorize and adjust. New bottlenecks, roadblocks, and impediments are getting removed all of the time and freeing up new capabilities. There are SO MANY dependencies in a software system or software project that you could NEVER Gantt chart it all out and execute a waterfall process successfully; attempting to do so would be crazy.

At any rate, we're having some fun building this Business Intelligence application for the customer that takes from about 5 systems and integrates them into one. It's hard, challenging work but we have a pretty good approach: we've isolated the "pulling data" problem from the "unifying and normalizing data" problem from the "present the data" problem. We now have a very solid foundation that can create some real velocity within our team. One guy on the pulling, back-end, and automation, and a couple of guys on the front-end making it look real nice.

The Real-Time Burndown

Probably the holy grail of software development or any project for that matter is to know how long you have to go until you're going to be done. This is a very important metric from a lot of angles.

In software as tasks get brought into scope for a current sprint or release, this spikes up our hours. We might think something will take a long time and it impacts our perception of completion time. But as we dig into our tasks and re-estimate how long they will take to complete, we get more accurate. By providing a system to keep estimated hours until completion at the aggregate for a release we can be in control as a team. All of the stakeholders can watch as things ebb and flow and hopefully the work is burning down in time to meet our deliverable milestones. By looking at big tasks (sorting by largest hours to complete) we can see our risk in the project. Start the big stuff now and knock it down fast.

The Release Manager is the Product Owner

What's a release manager? A marketer. A public relations fellow. Someone that cares both about the customer AND the product development team but in no specific order. This person is the best possible person you could have on your team or company. They can turn a bad project into a good one and a good one into a bad one. If you have someone acting in a release manager capacity that is either A) all about the requirements or B) all about giving the customer everything they want regardless of cost, you're in trouble.

Train people in this role how to help you out, provide air-cover, and also how to serve the customer. If you are the guy/gal responsible for delivering the product find someone who complements you very well and understands how to communicate, deflect, and the like. I'm not yet sure if the Release Manager needs to be technical in a software project but I believe the answer is definitely yes, since if they aren't they can't deflect and backlog as necessary, that would end up falling to you.

Be Fair

How can you be fair in work? How can you kindly deal with other, hard-to-deal with people? Consistency is probably the number one way. But what if you're consistently a jerk, or consistently unfair? I believe that by being consistent in our decisions and ways of thinking (your process), people will have a way to view your inner world and question your—sometimes possibly unfair—intentions. Be open, be a book. Expose your reasons and why you're doing what you're doing and you'll get better at doing it.

Date-Driven Development

"What are we going to get and when?" Not the easiest question to answer sometimes. When the requirements are vague and the climate is tough, you still have to be able to operate. Understand how to deliver the minimum possible deliverable that qualifies as that requirement by name. Try not to get into too many details with the highest-up sponsors. If you do get into details with them, renegotiate the dates and bring them into your process.

Planning Shouldn’t Be a Chaotic Process but Often Is – Without the Right Authorization

Why? Because it involves the commitment of others. You can create a plan for yourself; that's fine. But it almost always—especially in business—has dependcies on others. If you are the planner, the doer, the leader, the driver, the actor, then oftentimes your presence and energy makes people uneasy. They see you as frazzled, needy, and chaotic. But are you? Yes, but only because that is your perception. As a leader and doer, you have to be able to be calm, cool and collected and communicate effectively with others about what you need from them. If you have a plan and your hell-bent to execute on it you'd better be very careful about how you come across to and approach others. You have to be patient and communicate very well. You have to sell them on what you're doing and why, how they're involved and necessary and how their lack of commitment or engagement impacts the organization. When you get push-back or lack of cooperation from people it is your job to do two things A) try to convince them to partake B) find alternate courses of action to continue to drive the program forward and get commitment and C) be ready to communicate about lack of participation and engagement to senior leaders. Doing Item C will most likely give you more power to engage with these people. Having support of your senior leadership gives you the power of coercion rather than influence. This "real" power can help you get very far in organizational projects.

This blog has moved

This blog is now located at http://kickmajorbooty.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://kickmajorbooty.blogspot.com/feeds/posts/default.

Technical and Non-Technical People; There’s a Big Difference

This is a huge distinction in people's minds in business. Technical people are the engineers, the doers, and often the coffee-getters of our organizations unfortunately. Non-Technical people wind up being the leaders and managers. But why?


In a way in business, it's a very large penalty to be capable of doing the work. Yes, there's an entire body of "work" in management but there are some people out there that really don't do shit and don't know shit; they don't add value. These non-technical people somehow find a way to become the managers and leaders of our organizations. But why and how?


In my opinion, you either know how to do the work or you don't know and you wind up telling people what to do. Business is a crazy world that's centered in strange ideas of power.

Is My Project an Unintentional Agile Turnaround?!

After a very long and trying month and a half on a new project, it may be turning around to a success?!!! Could it be?! Maybe. The suggestion was even made by a senior coworker today of having "more than weekly" recurring meetings with the client to sync. I joked about having "Daily Two-Hour Standups". We're in a development rhythm (finally) and that is really satisfying. I'm really the only developer, though. That's been hard. Really long hours. 12 hour days are typical. Our project and delivery schedule is as follows: Plan Mondays and deliver Fridays. I twisted arms to add a ton of risks to our risk register today. Seems very simple moving forward but it's been hell getting here. I'm not sure how many teams work the way we're working. We have a very difficult problem we're solving; many moving parts and tons of senior-management pressure. Dates and deadlines. It's fun at the moment and I hope going well. I have a huge deliverable tomorrow and I've learned so much on this project about data movement, ETL, and SSIS. Also about people and leadership. Roles, and stepping down when you can. Let quality people be quality; let them help you out.

I'm designing an automated business process that removes 204 manual hours of work monthly. That's fun and satisfying.

Mind the WIP and the Whipping

Two skills for PMs. Make sure that the work in process is going well and that impediments for the workers are removed. That is your job. Another job is to watch how much you are whipping your employees. Assume they are smart and good; doing a good job, with good intentions. Guide and lead them. Mind the whipping and don't whip too much. Choose carrots (vision and leadership) over sticks and whips.

The Demo Could Happen Any Minute

Don't be a slacker. Be very clear on what you're doing and why. Who knows, the customer could join you right now and want to see what you're doing and why!!!! Be prepared.

No matter how paranoid you are, you’re never paranoid enough.

Afraid someone is watching you? They probably are.

In a computer system, anything that did once exist (all events and data) could be logged into a database and analyzed either now or later. This data could be used against you but it could also be used for good. How so? In making our software better! But what is the cost?

The more parts of our software that get "instrumented" (hooked up to log actions into a database), the more at risk we are for losing our privacy. And A LOT of the parts of our software are getting instrumented and hooked up to online databases. You could build your house into Fort Knox, but you need a data Fort Knox as well and things like "The Cloud" conflict and compete with that. Many companies today instrument their software in order to learn how people use their software. They use this data to make the software better; but there is a very big cost to this! This same data could be stolen or subpoenaed and used against you. Not exactly what you want.

In short, be very, very careful and very, very paranoid of what you're doing on your computer and online … they could be (and probably are) watching you!!! ; )

How Could You Ever Test a Product If You Didn’t Know What You Don’t Know

I'm reiterating my point of getting the product into the hands of the customer or the testing team as fast as you possibly can. A developer cannot be a standalone entity, operating in isolation. All individuals need feedback and we cannot deliver quality unless we have an on-looker or customer. We need an audience or we are really just performing for ourselves, without feedback. We need a mirror at a minimum! Give your code to the customer and then determine what the portfolio of needs and changes looks like. Be agile.

Touch Touchy Subjects Tenderly

I'm definitely not the best at this but I think I'm getting better. Some things are taboo, some things are sensitive. This is true in both work and life of course. With specific respect to work, however, we definitely need to figure out the best way to play the politics, get ahead, and engage in the (potentially difficult or touchy) conversations that we need. This includes subjects such as compensation, coworkers, the work itself, and assignments. "Managing Up" is a skill that is talked about a lot but it is neither a class I have taken nor a subject I've read about. I just did a quick search for books on this subject: http://www.amazon.com/Managing-Up-Forge-Effective-Relationship/dp/0385507720 Does anyone recommend any good books on managing up and doing well at politics in the workplace?

Let the Customer Drive the Priority

As a product developer, you have to be able to 'let go' of your product. It's not for *you* anyways, so get it out of your hands and into those of the customer! I'm building an app for a friend right now and am finally to the point where I am willing to give him access and let him test it and comment. That's a big milestone! I am sure he will have feedback that I do not expect. Your users are your best testers. I don't want to be perfectionist about my product and need outside help. I don't want to float too green of a banana but I think it's good enough for now. He wants the app and deserves to know what state it's in.

Solving a Problem can be Disappointing

I was on the phone with the Hewlett-Packard Customer Support line this morning and (without the agent's help) figured out the solution to the problem I had called about. When I announced the solution, the customer service rep said, "You sound disappointed that you solved your problem." And I answered, "Yes, I do." (It shouldn't have been the case, I don't think that *I*--rather than *he*--had figured out my problem.)

I would add to this that there are other problems that when solved, there is no real "EUREKA" moment. As they say, "Huh" is a better discovery than Eureka. The truly big shifts do not occur via some drastic "explosion" of change, but rather a new realization or perspective that can be as small as "huh", or "that sucks".

An example of this is working on a computer bug that when you solve it you have tried so many things that cause so much time and pain that when you finally do solve the thing and make it work you are simply disappointed that it was THAT HARD. Such is life.

Lag Time, Patience, and “System Perception”

People have very different reactions while waiting for computer systems (any process for that matter) to complete or change. Take for example launching a program on your home computer: you click a button and the "wait cursor" comes out. What do you do? Get angry? Wait patiently? Hope for the best? Some people tap their foot and get anxious, others watch and wait and think about what might be happening and how things might be working. We have a chance to be introspective about systems other than ourselves.

We can witness the same behavior on the road every day in our driving: some drivers are patient and don't give too much thought about what the drivers around them are doing while others are very critical of the other "stupid" drivers. I'd say that the way we think about other systems and what they are doing is a very clear reflection of how we think about ourselves: Are we patient? Are we forgiving? Are we intelligent? Are others intelligent? …All of these things cross our mind in computing and in other life-systems as well.

In this way, I recommend that we be more patient and seek to UNDERSTAND what the other systems around us are doing and why…and in that process we will learn much more about ourselves, our intuitions, and how we are actually impacting the systems around us. Thinking at this level will help us change things for the better.