Never Ever Ever Ever Underestimate

In our work lives we frequently have to make and keep time-based commitments and estimates and work to schedules. This sucks but it's sometimes and for some often a reality. How do we cope and deal with high-pressure situations like this? By NEVER UNDERESTIMATING!

The old axiom is "under promise and over deliver" and that really is the goal. It helps with work life balance and a variety of other things. Doing this well has so many benefits it's amazing. I hope you can do this well and get good at estimating "just right" to give yourself some breathing room but not be overly padding your estimates such that's it's ridiculous and you're seen as lazy.

Appreciative to have finally landed/settled with my career (at least for now)

I was really good at building web-based systems when I graduated from college in 2000…at least for the time in my head. I was quite confident about my skills to say the least (cocky is probably nowhere close to an understatement). But my problem at the time was that I hadn't yet been able to realize my vision and in a lot of ways I was pretty insecure. I was very ambitious and wanted to build really big systems—and did build some—but I wanted more skills so I went back to school so I could achieve more.

When I went back to grad school at the University of Washington Foster School of Business I learned a few things:

1. People at work and in my life expected that I was getting an MBA, not a technical degree (I was getting my MS in Information Systems at the time)
   
2. I learned A LOT about how to build systems that matter to people; I learned that business and business process is the real need and driver behind IT systems and that IT systems should play second fiddle to these more important factors. In this way I become much less of an idealistic pro-technology at all costs nerd.
   

Because of #2 above, I decided that I really didn't care too much about IT anymore and what I really wanted to do was get in management and AWAY from IT. I tried.

Fast forward two years from then to last fall when I was unemployed and needed work. I got a job as a software developer again but I was really rusty with my skills by this time even though I was probably WAY sharper analytically and from a thinking perspective than I ever had been. It took me many months (9 now?!) to feel confident with my software development skills again. I'd now say that I'm a pretty good software developer again. And I'm not worried about being one at the moment. It doesn't bother me that I'm writing code again because I know that I am also a talented analyst and project manager and I have my masters degrees and PMP certificate under my belt; my confidence is currently pretty high.

In total I guess I'm saying that I'm very thankful and appreciative right now for the roads I've been down and the place that I'm at now with my career. I'm 33 years old, 10 years out of undergrad, 5 years out of grad school, and I feel pretty good. I'm a consultant for a pretty cool company and make a pretty good wage with benefits. I like what I do. I'm technical and non-technical, businessy and nerdy at the same time. I think that I can go this way or that in my career (make choices that don't have ridiculous costs and consequences) and I really like that agility. I'm happy I finally landed here, it was a very long road.

Rhythm and Cadence (Predictability) in a Project or Program is Hard to Come By

It's very desirable to get into a pattern where you plan, then work, then deliver, then review, then do it all over again. The goal is to limit interruptions and make things predictable. Let the people do their jobs and don't let the jobs conflict or adversely impact one another. Harmony is a good word here. Of course this would be nice but it's not always possible. These phases, people and interests often overlap and sometimes get out of sync.

My current work project has a fairly decent cadence but it is not perfect. Overall we're doing a pretty good job. We usually plan on Fridays and deliver on Fridays as well. We commit for the next week late Friday. This gives us a day to assess where we're at and what we're going to do next week; but of course these plans can get interrupted by changes in the following week. In our project, the policy is "what is committed is the sprint" and everything else is the backlog. If we finish the sprint early, then we can work off of the backlog items of course. We've been lucky to not have too many fires. Sometimes the sprint itself generates more backlog items.

Product Manager, Business Analyst, and Solution Architect Roles: They’re All the Same

In my opinion a Business Analyst is someone who "gets it". I would say the same for a Solution Architect and Product Manager. They understand technology and programming well enough to determine the solution with the customer. They also know and understand business well enough to think through what's practical, pragmatic, attractive, and scalable from a business perspective. They are smart enough to work with developers and engineers to explain the solution requirements and do some translation.

Contrast the business analyst type person with a database person (what are their skills other than they can write SQL and work with databases?), and with a user interface specialist (who knows how to make a pretty user interface but who cares?).

Where's the process person in all of this? Who's the person that cares about the system and customer more than they care about a particular technology or capability?

In business in the end it's all about making kick ass products and services that people love; it's about engaging and possibly entertaining people. Loving one side of things (business, technology, user interface, design, etc.) too much is short-sighted. Focus on the customer, the market, and how to make as many people as happy as possible; and forget about yourself in the process.

Being Serious about Attempting to Deliver Quality is the Same Thing as Confidence

From where does this type of confidence come? How and from where do people get it? Experience? Is there a source where I can find more of this energy?

You can't have confidence all the time. Sometimes you can "act as if" and get by but that not everything; unless you're in sales. If you are ever on the hook to do the work or job yourself (engineer a solution or produce a product), you have this sense of urgency and serious about yourself and that is not confidence. In fact I think that having that sense of urgency and seriousness about yourself actually DETRACTS FROM your confidence in some way. Confidence can be thought of as arrogance.

Is it so bad to doubt or be skeptical? Maybe in sales.

I guess I'd rather be scientific and fact-based rather than overly excited about "opportunities" myself.

Being confident all the time isn't possible but we want it for ourselves. When it comes to work, in the end SOMEONE has to be the one who takes the lead and ACTUALLY delivers the product with the skills, resources, and connections they have to the customer. This product has to be delivered to the level of quality that the customer actually requires, to a "confident" place. Delivering quality, to me, is confidence. But to get here requires much, much more.

I Hate You, Copy-Paste Coding

I'm doing it right now. It's the worst. You have to do it sometimes but when you do it, you create redundancy and inefficiency in your program.

Alternatively—and sometimes there is no alternative—centralize your logic and create reusable components. Time-constraints and complexity sometimes (frequently?) prevent this from happening.

The innovation can and will come later. Doing things poorly is often a good lesson for how you'd do it better next time.

Avoid Creating Roles - Everyone Does Everything

This is the type of culture that I want in my business. BluWater Consulting's scrum practice did this very well. Everyone on the team had a variety of skills from UI to the database and everyone TOGETHER was responsible for delivering the product successfully. The bottlenecks in the team were what they were and there was no preconceived notion that the company could perfectly staff a project with just the right resources. So they instead hired good balanced players and made sure that OVERALL they had the competence available to build the solution. They started into their projects aggressively and the team sorted itself out and figured out how to organize in order to deliver as effectively as possible; roles were project specific and always will be because there are different casts of characters on every project.

My current company is considering making teams of UI specialists people and teams of Database specialists generally and for each project. I'm not so much into the idea. I don't think we should be creating practice areas; we already know who the specialists are. Let's not take the focus off of shipping the best product with the resources we have and think about "organization". We need to organize around THE CUSTOMER, not ourselves and our competencies!

Yes, some people are talented designers and very artistic and others are highly mathematical and systems thinking but let's not pre-focus our teams on concepts other than the customer and getting things done.

Keeping the Baseball Book

When I was on the varsity baseball team I spent a lot of time as the "book keeper" because I was not good enough to be playing. I got REALLY GOOD at keeping book in fact. That's probably how bad I was at baseball.

I was doing programming working on my project for the customer today and thinking about some of the conventions and practices I am following on it—from coding standards to the way I format the font and release notes when I share the product with the client—and was reminded of how I used to keep the book. I used to be VERY anal about how I would keep the book and I would not let some of my teammates keep the book. Even they adopted my conventions and followed them. I heard years later that my format of book keeping on the baseball is still in tact; it's called "Veal book" and the team regulates it.

The goal in any business is to be consistent and let others see your quality ways through the conventions in your products. Be good and careful with your products. Put on fit-and-finish. It shows through.

Refuse Help That Prevents Greater Things from Happening (And Other Lessons I Learned from My Current Project)

I recently had the opportunity at work to accept help from a new resource. Accepting his help would have taken a lot off my plate and freed me to do other things; it would have taken a lot of stress from me. I came to find out after the resource was provided to me that he was also expected by a paying customer at the same time in her group full time. Because my project has a limited life and I believe I have no more right to the resource than a paying customer, I decided to let the resource "go" and I am now back working primarily by myself really long hours again; it's not fun. But I don't regret the decision at all; it's better for everyone (except for maybe me, now)…I'll elaborate.

Other than this lesson on the project I've learned a lot of other things, too. Below is a list of my top lessons from this project.

Some quick background first: I'm new to the company, new to the client group, and new to the type of project/product being produced: a reporting system re-engineering existing reports and merging several systems into one. I've been with the company for just under three months now and was hired on this project as a business analyst / delivery project manager.

Top 15 Lessons from my current project:

1. Ask hard and tough (AKA good) questions in job interviews about what the project you'll be working on is, who the team is, and what other projects the team is working on; don't get involved in projects that are under-staffed. Ask about the company's recruiting plan if you identify that there are not sufficient resources to finish the project to the customer's timeline.
   
2. If the project is getting behind, don't be a fall-guy / hero and jump in and do the work yourself; raise it up the foodchain and stick to your role as manager; not doer. This is one of the primary places where I fell down on this project.
   
3. Ask what priority your project is in the overall scheme of things within the company.
   
4. Ask if the project is "just a project" or if it is more likely a larger program / sales opportunity.
   
5. Ask the company about how they think about and implement work-life balance
   
6. If a long-standing technical resource on the project tells you that a request from the customer is non-standard and out of the norm, raise that issue up the flag-pole as fast as you far as you can and as soon as you can.
   
7. Be good about openly communicating risks; don't be paranoid.
   
8. Don't start in groups where you are expected to be a subject matter expert from Day 1 if you are not a subject matter expert.
   
9. Be willing to make timelines that project a ways out; they can always change. Think of things "thematically" and long-term.
   
10. Never let non-technical managers drive technical meetings or participate in coding sessions. Follow "Pig and Chicken" rules. Chickens like sales people are only partially committed while you as a pig are on the line to deliver it all.
    
11. Create an "electric fence" between the Pigs and Chickens (engineering/delivery side and sales side of the business). Don't let these two worlds cross-pollinate at the lowest levels of the organization but ensure that there is a VERY STRONG interface between these sides at the higher levels of the organization. Without this interface/partnership/discourse you really don't have a business at all; rather confusion, finger-pointing, unfulfilled expections, ridiculously long "death marches", and customers left in the dark.
    
12. Kill "old school" project managers who try to manage everything by dates and matrices. Not everything will fit in the matrix so forget about it. Keep a product and task backlog and share it with everyone. Buy and use good IT tools like AxoSoft On-Time for managing your projects. Make sure everyone has an account.
    
13. Establish a recurring delivery cadence and rules about work-life balance. Don't expect the project team to kill itself to make the customer happy.
    
14. Stop the sales side of your business NOW if your supply side (hiring or delivery processes) cannot keep up with the demand.
    
15. Always think mathematically and in a clear, data-driven way about demand (who needs what by when) and supply (can we get it to them)?
    

Overall I learned in this project that business is about risk and taking risks. Some people can tolerate more risk than others. I took this job not thinking of it as a risk but an opportunity. It has definitely been an opportunity for me to learn a lot about this organization and about getting things done. I also learned about a new subject area: report system automation and system integration.

I hope that my company matures its operations rapidly, that my current project wraps successfully and becomes a program/lasting account, and that my next project is fun, insightful, and does not require so many hours. (I worked a 14 hour day today BTW, and two weeks ago I worked 40 hours in three days. That is NOT THE GOAL!)

Why Wait for Someone Else To Do It When You Can Do It Yourself?

Building Big Databases

This is probably one of my bigger passions in life. I'm not sure why I like it so much. It must be a "control" thing for me where I want to have control over a domain or set of people; a system. I want to create new domains that I can advise.

Always Fix the Weakest Relationship in the Team

Dealing with talent is tricky. In my company we have a guy that's good at organizing people and things and a guy that's great at selling things and dealing with perception. These two—if they knew each other well and how they can benefit each other—would be the perfect duo to kicking major booty. They don't currently realize how critical each other is to their mutual success—and mine. I'm trying to put bugs in each of their ears so they can start working together. Teams require strong individuals and strong relationships. Always fix the weakest relationship in the team.

The Middle-Ground Between Developer and User

What the developer cannot see (but tries to understand) is what the end user sees. Through feats of magic and mayhem, the developer tries his very hardest to be in the shoes of the user and understand all of the needs that the user has. If the developer did not understand (or think he understands) what the user's needs are, then a solution could not be developed and delivered. Yeah, a developer could "totally wing it" and shoot in the dark for a miracle but that's not the goal.

The developer has to put herself in the shoes of the user but can never BE the user because she IS the developer. It's hard to be two things at once and this creates a blindspot.

Speak Your Needs

Not too many people are good at this. I'm not. As people we have to get a lot better about this. What do I need? What do you need? How can I help you? Many of us are probably either unwilling or unable to tell people what we really need. Some of us—myself included—may believe that they don't NEED anything…that they're "good". But none of us are good. None of us are complete. None of us are without the need to connect with and relate to other people and key concepts.

I'm setting a goal for myself to tell people what I need more often.

Try to Be Aware of the Consequences of Your Requests

For every action there is an equal and opposite reaction.

Don't just ask for stuff because you want it. If you're doing that, then it means you don't really understand what you need. Maybe you don't need anything at all. Maybe you are not deserving of using the thing that is given to you. Maybe if the gun you want is put in your hand you will shoot people with it. Be careful on what you wish for.

Trust is a big thing and something that is very hard to manage.

Sometimes It’s Good to Assign Blame

When you get to the end of a project, it's good to level with people and tell them how you feel. Not a full-on berating of the individual but an assignment of responsibility for consequences rendered. Do you agree?

Consulting as Learning to a Job Better than Anyone Else Can Do It

In the company that I work for we have a very flexible way of working. It is very "agile". There are no managers per se, although the pecking order is pretty clear at the highest levels. When it comes to the "consultants" (workers), however, things are very open and undefined. This is both good and bad. For example, in me looking to figure out what I am going to do next, I am likely going to find someone within the company who "needs help" doing what they're doing. This person could also be a client who "needs help" with what they're doing.

One of the following things could happen:

• I help them and free them up so much that they can move onto something else (I become the owner of the role or function)
  
• I work with them and figure out the my skills are way different or are complementary to theirs and we grow the team together
  
• I go try to do what they're doing and it is either not my interest or not my skillset and I bail
  

I'm hoping in my next gig that I find #2 but I'd be just as happy if #1 occurred.

Who is the risk/problem on your project?

Pray it's not you but beware because it could be. Figure out what you have to do/adjust in order to comply and take the pressure/attention off yourself. Do everything that's in your power to get out from behind the impediment, project, or task you are facing. If the project / problem / focus does happen to be someone other than you, then make sure they know it but be kind in how you tell them about it. Help them through the process and change curve. Don't embarrass them. Give them a moment to shine. Make the focus constantly change. Everyone should be the impediment / bottleneck at least once in your project. If they're not, then they're not critical path or necessary.

Be the guy that *is* the bottleneck

At work you're in a much better position if you are the guy that *is* the bottleneck than if you're the guy that *creates* the bottlenecks. Don't be the latter. You'd hate to be the guy that makes things slow or inefficient in the system through his actions in/on the system, tasks, and people. We all have limited bandwidth but don't be the guy that creates limited bandwidth in others. If you are this guy, question your policies, actions, and practices and determine what you can do to empower others and the system to be their/its best. Facilitate the production of the system; don't insist that you create it yourself. Be responsible for creating both the product and the process! The system (in my opinion) is intended to be created by/for the people, not something to be imposed upon or forced upon them.

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.