When to Delegate, When to Collaborate

Most business processes require COLLABORATION (shared activities) and DELEGATION (solo activities). Sometimes you really just want to GIVE work to others and not worry about it and other times you want to SHARE work with others. There are times for each modality. Some people use one too much.

On my new job I am way more in the COLLABORATE mode since I am still learning and want to build relationships with my peers.

Here's how I like to work:

1. COLLABORATE
   
   1. Find the work and understand from the customer what it is, what its success is
      
   2. Share the work and needs with your technical collaborators and figure out what needs to happen for this thing to be successful
      
   3. Determine everyone's roles in the production of this product? What will be shared, what will be solo?
      
2. DELEGATE
   
   1. Do the work and finish the work
      
3. COLLABORATE
   
   1. Determined what you learned and repeat
      

Lots of collaboration. The delegation only gets done after everything is defined and clear, and then you send people out on their mission; very little ambiguity is left. I like it this way and I think this builds better teams and products.

What Is the Impediment Blocking?

"Impediments" prevent us, our projects, our processes, and our products from being efficient, effective, and complete. But not always at the same time or in that order.

Below is a brainstorm of what impediments cause by type. I'd like to know your thoughts.

Personal Impediments

• Blocking "me"…what does that mean? How? Why?
  

Project/Task Impediments

• Blocking start
  
• Blocking completion
  
• Blocking continuation / next step
  

Process Impediments

• Blocking flow
  
• Blocking completeness
  
• Blocking quality
  

Product Impediments

• Blocking completeness
  
• Blocking quality
  

Do You Want Daily/Weekly Rhythm and Cadence or Real-Time-Collaboration?

When you're working hard toward getting to the finish line, many questions come up. Sometimes it's best to get information / input when you need it and other times it is best to DEFER getting the information. For example, if you customer joins you on a daily call, you can save all questions you have for that daily call and work on everything else. If on the other hand, you need/want the input from the customer NOW, you have to make the call and put up this "blocking issue".

Randomization of resources works both from customer-to-dev and dev-to-customer. Neither one of these parties should want to be constantly pinged by the other with needs and questions; that is unless their mutual goal is THE PRODUCT and the customer is HAPPY to be bothered with questions. If, on the other hand the project is seen as a burden and something that they are both going through together (A PROCESS), then they should touch base on a daily basis.

Thoughts?

Quick List of Ideal Software Development Project Commitment Policies

1. I work as much as I want to work; I can kill myself working a lot if I like. I can be a "rock star" and do all of the work for everyone if I like.
   
2. People get paid for the amount of work / points they deliver to (it's a competition)
   
3. We as a team are responsible for delivering to our commitments
   
4. I am responsible for predicting how much work I can do for a sprint
   
5. I am responsible for delivering the amount of points / work I committed to for the sprint
   
6. If I do not contribute my "weight" in the sprint, then other teammates have to pick up my slack; we are in this together

Perceiving a Constraint

We don't always realize that there is a constraint somewhere. We don't always realize when people are hurting, are overloaded, or overworked. I've been killing myself on a project (regularly working 12+ hour days) for the last month. It's not a reasonable or sustainable pace that I'm keeping. I am unhappy and the customer may be finally starting to become OKAY. They had really high expectations and we had a fixed resource constraint so I jumped in and did a lot of work. But my over-working is about to come to an end.

Hopefully soon, the customer will FINALLY REALIZE that there is a constraint in place and I have been that constraint. I can only do so much and that has to be understood. I can no longer continue the grueling pace that I've been under.

Be careful what you wish and ask for. Be careful of what you sign up for. Try your very best to set REASONABLE EXPECTATIONS with people and get out of the business (if you have to) of doing things above-and-beyond or setting stretch goals. You can only stretch for so long; at some point you will break.

Do Something New without Breaking Everything You’ve Done Before

Systems are weird in this way. Adding something to your database / model COULD BREAK EVERYTHING. Getting good at adding things to your model without breaking everything you did previously is a very important skill to have!! Taking good notes about what you did do is pretty critical here. And being able to "undo" is also very critical…

The Project is not the Project Management, It is the Work

Don't confuse making fancy charts and graphs and figures and all that with the project itself. The project itself is that which produces the product. Nothing else.

Programming Should Be a Spectator Sport

I'm working to a deadline right now (yes, I have time to write a quick blog post when a good idea comes my way!) and am keeping track of my method and what I'm doing / producing and my assumptions and bugs generated as I go. I'm using MindJet MindManager, one of my favorite pieces of software (if not my favorite indeed). As I go, I am iterating and going down the road and making notes and fixing things and logging what I did. I'm tracking my progress in a document other than the code. I think if someone were to write a web service / site that sat on top of my MindManager file then it could be interesting for my project managers, team, or customer to look in and see what I'm doing. As I create new objects in the file, it would be a running log of what's going on. They could write things into what I'm doing and say hello, correct me, direct me and answer questions.

Bottom line, I'm going down the road HARD to make a deadline and deliverable and making A LOT of assumptions plowing the path. I'm prepared to review them LATER, but not now because I am busy and it would take a long time to "catch someone up". But if they were watching or could watch my "timeline", then they could see what I had been doing and we could share that information.

For now I will work in MindManager and plan to share my assumptions and questions later; after delivery.

This process could be improved.

Forget about Project Managers

Leadership, partnership, project, and business success happen at the Program level, not the Project level. Very few peoples' fortunes or successes are made on single projects but rather through well planned strategy and well considered tactical execution. If you want to "win it big" on a big project, go out and buy yourself a lottery ticket instead; save yourself the headache.

If on the other hand you are serious about turning around your business and are not sure how to do it, think twice before you go out and hire someone to "do a project for you". Instead, hire a program manager or "true consultant" and invest for THE LONG HAUL in someone who can understand your business and professional needs OVERALL and help you transform your business into what you want it to be.

Projects are temporary endeavors and necessarily have an end. Programs do not necessarily have an end; and their purpose IS sustainability, which is VERY DIFFERENT from the purpose of projects. The purpose of projects is to "have an impact" or "kick major booty" but these things are not sustainable or reasonable by themselves. There has to be a plan!

Management can't be careless or wild in today's complex, competitive environments. No project can deliver successfully without having something like a Program Office or support organization who can "catch it" and its results and maintain the things that it did or didn't deliver. Nothing in our universe is standalone, atomic, or unaffected by outside forces, projects included. They are not atomic and cannot be treated so; they must be treated as a program or portfolio.

People who shoot for big results through one-off projects are the true entrepreneurs and risk-takers of our era, and probably stupidly so.

Maybe I Studied Management So I can be a Programmer

I have a Masters degree in Business Administration (MBA) degree from the Univsersity of Washington Foster School of Business; one of the Top 20 business schools in the nation. I earned that degree about four years ago now.

I read about management, study management, and leadership frequently. I care far more about people and processes than I do about particular technologies but I love technology. I have to be a technology builder sometimes; the engineer; the guy that actually makes the thing. And I am good at making the thing…sometimes…

When I went back to school, I wanted to improve my technical skills and learn how to make "bigger systems" and increase my chances of getting promoted and hired; more upward career mobility / momentum. When I went back to school I decided not to do MBA school and instead decided to do the Master of Science in Information Systems program.

But when I finished my MS degree we were lured into doing "just a bit more school" and get our MBA also. I and quite a few of my classmates—probably half—chose to take this route. So we have MBA degrees also. What good has this done? Gotten me a lot of jobs.

I am technical and not technical at the same time. I can dumb it down. I am business and not business at the same time: a walking contradiction.

Let’s Bring Interests Together

How many levels of translation / communication / management are required to support / separate / distance "competing" world views / opinions / people? What if they weren't competing at all but had the same goals and interests in mind but just didn't realize it?!

Examples of this pattern exist in technology (say between "marketing types" and "mathematical types"), in politics (say between Liberals and Conservatives) and in religion (say between Christians and Muslims).

The goal in my opinion is to have good and healthy dialog, debate, and constructive action for these two groups. I don't think war is constructive; maybe some would disagree.

How well each of these sides is organized is interesting but how about THEIR INTERFACES? How well are the interfaces organized?! Probably very poorly.

Let's ORGANIZE THE INTERFACES between competing factions toward productive shared means and goals; let's program manage this stupid dysfunction!

You’d Rather Plan, Do, Check, Act than Do, Do, Do, Act

Plan your work and work your plan. Quality is job one. Sometimes these things don't come to fruition. Sometimes you are left alone to do everything, no time to plan or to check your work. When the work is checked, it results in another "Do" cycle and you are randomized while in the process of doing another key thing. You can get out of this spiral but only if you have help and process.

On the process side, if you REFUSE to work until there is a plan that is one way. If you INSIST to not start the next thing until the previous one is done, you will help yourself. But these things aren't always possible. Insist that people get into a reasonable cycle and care about the project/process overall. It has to be fair or it will never succeed.

On the help side, you can get help. You need at least one other person to PLAN WITH and you need people to give the customers time while they CHECK. And you need to be given the chance to plan and act on what was checked.

You Can’t Manage It if You Can’t Do It

Identify the Bottleneck and It’s Source

Where is it? Is it in your project? Your process? Your tool? Your team? You? You have to determine it. Sometimes it's tough, though, hard to identify. But if you have a high enough sense of urgency and focus then you will get very good at determining WHERE the current bottleneck is in your process or system and what to do about solving it. Be the master of your domain and seek to continually grown your domain.

Create Influence from Wherever You Sit

Whether you're the big boss or a little pee-on minion or somewhere in between, create influence in everything you do no matter what you do. Be upbeat, be strong, be positive, be persistent, get results, and fight for what's right. Get things done and charm people.

Care about the Content of the Matrix more than you do its Form

Sure, you can make a table, a matrix…good for you. But is the data that you have just shoved into it valid, interesting? Spend your time focusing a lot more on DATA QUALITY than any rigid ideas you have about "this must fit". Maybe it simply doesn't fit and you have to break your matrix in order to accommodate a new item. Be flexible.

It Will Never All Fit into the Matrix

There are people in this world, myself included, who need to think in terms of matrices. I don't like to think in this way but I often must. I am building systems and databases in my trade and, as I said in a post earlier today, things either fit or they don't: they either fit into a/the matrix or they don't. It is not my INTENTION to think in these terms but I must on many occasions. Things have to boil down to a matrix.

I know a PM who is very good and talented at his craft and he frequently likes to put things into matrices. I think he overuses the tool in fact. When I'm building systems, many matrices are required. But I don't want to burden the customer or my peers with this extremely rigid way of thinking. Thinking in METAPHORS is much easier but not always possible. Asking questions and developing a mental model for MYSELF is often good enough. "Requirements statements", rules, and policies are often good enough to be clear. Knowledge can be represented in very many forms and the matrix represents just one. The world is not a database and never will be.

If you are a matrix-thinker, or a matrix-over-user, or are required by your line of work to be a matrix user frequently, consider your audience and use matrices and matrix-like-thinking sparingly. People are systems, not spreadsheets. Use a variety of methods and don't think of the world as if it will all ever fit into a/the matrix. It won't, so give it up!

Constantly Improve the Interface Between Your Change and Presentation Layers

Make a very clear distinction and separation between your "change layer" (that which changes, is variable within your business, etc.) and the presentation. That which is quality, confident, and customer facing. Decouple these things and separate them at all costs. Be consistent with customers and constantly work with your trusted team to clearly define and improve this interface.

Capture and Surface the Waste in Your System

Let's say you're building a system with a few inputs and a lot of outputs. They system is complex. You know that "garbage in garbage out" is true but there are also wastes within the system itself. Say you have two garbage inputs and want to make a good system. So the saying would be "garbage in, gold out". So if some of the garbage is gold, then how do you differentiate the two? You have to squeeze the garbage out and demonstrate the gold. You only know the gold is gold because you know the garbage is the garbage.

Tweak and Improve the Model

What is the model? Who cares about it? The model to me in work and business is the shared mental understanding between service provider and customer about what the current problems are and what possible solutions are.

A "good model" is shared and exhibits a few other key properties: resiliency, constant improvement, change, innovation, and frequent new insights and enhancements.

A "bad model" is one that is stagnant, one-sided, confusing, unclear, unshared.

I'm working on a project for a client right now that in my opinion has a "bad model". I am building the product and model that represents it and it is currently bad because I think I am the only one that understands it. This is the worst possible place to be in; but also potentially the strongest if you understand it and communicate effectively about it. Getting to this place of realizing a "bad model" comes from poor communication, lack of mutual understanding, poor collaboration, or a fullness of delegation and lack of care. Hoping for miracles will not create good models by itself. As I improve this "bad model" into a good one, it is my hope that the customer will start to realize that the bad model can potentially be good if we decide to build it together; but it requires cooperation and partnership.

We have to build a better reality with each other. I cannot build something "for you" without your input, knowledge, needs, or voice.