Sometimes you gotta call for support

I got over my technical head on a work problem today. I need to make this (what I think to be) really hard report for the customer. It uses SQL processes and whatnot that I've never encountered, so I'm basically quitting until I can get a second set of eyes.

I'm not going to keep billing for work on something that's beyond me, so I stopped.

I emailed my boss and told her that I was doing this and listed about four or five others in the company who could help me with and/or do the task.

I think this is a good thing for me to do.

Separate the concerns

It's critical to understand how to do this in our lives. We should never "pool" our concerns, we should *separate* them. We should not panic. We should parse our problems out and make them clear, tangible, and distinct.

Good, sustainable solutions come from this mental process.

You're lucky if you have a knack for this, you're probably cursed if you don't.

When a five minute phone call saves our butt

This is the reason that good consultants and a healthy personal social network are essential.

Without our advisors and experts, we're nowhere. We can read and dig in and shoot in the dark, but sometimes we need consultants and experts to *help us solve our problems*; we have to escalate.

The reason I emphasized the "help us solve our problems" text above is that this is absolutely critical. We have to know that we have problems. We have to know that we have to solve them and we need to know that others can help us do this and that when the answer is given that we are able to apply the answer ourselves!

You don’t have to code it but you do have to pseudo-code it

You're nowhere unless you understand how the software either works or needs to work. This is the gap, generally speaking.

If you don't understand how the software works now, you won't be able to bridge the gap between the software devs and the business.

If you don't know how the business works now, you don't know what you're doing or why. You're about to get fired; you're dead weight.

Somewhere between these two worlds are people with the skills to bridge that gap; to bring needs into reality and to bring technical opportunities and problems into the light of day.

These people are the real leaders in our organizations; not people who take one side or the other but get both intimately.

The “Business Intelligence Analyst” role

Let's create and train more people to do this!!!!!!

This role understands "the process" of interviewing business customers and creating software.

They can analyze people, data, and processes and create workflows that work, be they on the business or data/software side.

They are high-level thinkers that are senior software architects and analysts that get down to the details of how to make the end solution, yet they get the info from the business (and from their consultant team). They are the glue in the middle.

They know the steps that will have to be made to get to the end of the engagement successfully.

The cost of not having the right consultants is the highest cost of all

Bringing a new resource into a project is expense but sometimes necessary. You might be stuck, you might think your solution will not be good unless you get the proper advice.

The value of a good consultant is very high.

My consulting skill is in Microsoft technologies and enterprise workflow. I can design complex, end-to-end systems that make big differences to businesses. But I, too, need my own consultants. I am not a one-man-band. I need help. I get stuck. I don't know certain things and need experts.

Building your team of experts and consultants is critical. The more challenging your work and scope, the more you'll need good consultants. You might want to hire these people, but you definitely need them. And they're going to be expensive. The good ones will win you REAL BUSINESS VALUE NOW and their cost is worth it in spades.

Just complete the f**ing scenario, already!!

The goal in most projects is to get feedback as soon as possible, meaning time is of the essence. People don't have time to sit around and wait for you; they'll get bored.

So, when you're faced with this reality, working by yourself, don't get mired in detail and "crap" that takes a long time to complete making something perfect. Rather, just finish the scenario, dammit!!

If you're not prepared to do "awesome" work, that's okay. Do your best.These customers will understand, support you and you'll be able to make another (better) product next time.

Don't worry about your demos sucking, their just demos and chances to meet people where you're at.

Are you pair-programming or double-billing?

Hopefully you're doing both and everyone knows about it.

Everyone should know that your output is going to be of higher quality when there are a second set of eyes.

Everyone should know that devs can "hang out" and help each other while also multi-tasking and doing other things.

If everyone knows about these things, then you have a good company and a good customer and all is good. If people question any part of this, all is hell.

Scrum doesn’t fully work without the Scrum Master

You can be an agile team, follow the processes and practices, but if there isn't someone *other than* the dev lead to do the planning and communicating, your project will fail.

One person cannot do everything. They cannot be both the developer, team lead, project manager, business analyst, and scrum master. It just doesn't work. There are too many hats, too many roles, conflicting priorities.

The Scrum Master (or someone other than the people on the hook for deliver and estimates) has to watch the budget and hours and estimates, etc.

Without this person the project and team will fail.

Stepped validation

Process:

1. I interview a customer about what they need
   
2. I share my notes from the conversations with my developer and explain to him the needs / problem.
   
3. I expect the developer to ask me questions and get the job done to *my* liking first.
   
4. The developer reports to *me* now, not the customer.
   
5. I still report to the customer, and the dev to me.
   

I call this stepped validation.

Things that people don’t care about

There are some processes out there that people don't care about or know about. This to me is *scary* territory, but it is also the land of opportunity!

For example, the process of publishing files to a destination is probably well baked but not very well understood by me. I had a situation yesterday were I published "with overwrite" to a destination and the overwrite did not succeed. So now, I am using the more brute method of "delete destination and publish".

In other words, I am doing something sub-optimal because I don't understand the process.

These sorts of areas are the land of opportunity. But when will I / we have time to look into / investigate them?!

If you don’t know how to do it, plan it

If you're on a deadline, don't start what you don't know how to do unless it's the last thing to do.

Know the process, know the data

Two really different things here: the process and its data.

The process is the thing that "works". The data are the things that the working produces (from both its working aspects and non-working aspects).

You can know the flow of the process without knowing much about its data. You may understand how things move and change but you won't necessarily understand what the data MEANS (or its purpose).

The skill/capability of knowing what the data MEANS is that of the data analyst.

The skill/capability of knowing how the data flows and its consumers is that of the process analyst.

Be both but you'll often have to choose one or the other.

Divide and conquer!

Technology = workflow

I learned a new trick at work today that lets me to make better, more complete, more interesting solutions now. I'm stoked.

Learning new stuff is great, but it abounds!

New technology changes the game and the workflow. Typical scenario:

Q: How did the thing/process used to work? What was the old workflow?

A: I don't know and I don't care!

People want new and better things all the time and when they learn them they forget what they never knew.

Projects one day at a time

In project work, the Statement of Work (SOW) is the legal document intended to keep things in order and denote the shared understanding of deliverables between supplier and customer.

Don't update the SOW with each change to the project, only big ones, new deliverables, removed deliverables.

Contract at a high level: Be a service provider and offer your services (planning, development, etc.) on a daily or weekly basis. Charge for the number of resources. Get your estimates right and try to stick to them. Communication change.

Projects don't have to be bigger than a day and a couple of people but often are.

When the job you have is not the job you took

We've all probably taken jobs or gotten into situations—be they marriages, cars, or vacations—that were billed as one thing in the beginning and then turned out to be something completely different in the end.

This pattern is probably the norm in fact.

I took my current job for the money, company, and idea that I would be traveliong between Dublin, Bangalore, Singapore for a week a month.

Fast forward to this job today and I am leading projects but I have not traveled outside of the city and I am mostly doing software development. The pay and the company are the same. I am okay with all of these things but they are very different from what I expected coming in.

So I have a choice:

1. Stay and "suffer" through what I have in front of me (the status quo)
   
2. "Force" things to change internally either by making phone calls or complaining or continuing to apply pressure (also status quo but with a bit more boat-rocking / risk taking) or
   
3. Leave and look for something elsewhere.
   

Those are the three basic choices I think we all face in our lives and jobs every day.

We are free.

Make people make their own assumptions

An important part of leading or delegating work is being able to paint a picture for someone of what they need to do.

Often as managers we don't know what the person has to do exactly but they do have to start so there is something to review! The product can be made "tight" later but first the bulk of the work has to begin. You should be 80% sure what the right product is yourself or you shouldn't have anyone begin. This is the definition of start. (Contrast with Definition of Done in the Agile methodology.)

In general the team *collectively* owns the work. The person doing the work is the knowledgeable and capable one and the on-lookers are able to comment.

Good systems are open and encourage a full review of the entire work product by those involved or curious. There are no egos.

By knowing your assumptions up front or empowering/enabling the worker to make assumptions and then vet/verify them with the customers, work can flow and customers can be satisfied.