I just spent all day in a meeting with marketing, engineering, serviceability and program management. This was a kick off meeting and as I am wont to do on occasion, I explained a couple of things about myself. I thought it was a useful requirements definition, sort of in the same vein as how to manage your manager. The first thing I shared was a list of traits and things I believe in. They are shared here for your edification and perhaps refinement:

1. I believe in state resolution. I am all about state resolution. I like disambiguation. Given half a chance, I resolve state. Given less than half a chance, I resolve state.

2. I don't believe in the right of infinite appeal. I think that once a decision has been made, unless there is substantial change in the environment that fostered the decision, we live with our decisions. No coming back to the table asking to reopen the decision because you don't like the decision.

3. Every profession, team, organization can point to a hero. They are generally the people that died and have a statue erected in their honor. Rarely do we need heroes in software engineering. A disciplined methodical process that gets the job done is very very useful. Yes, methodological is a word. <little inside joke>.

4. Drama is no fun. I was a thespian in high school, and even had the lead role in Mark Twain and the Garden of Eden. In my professional life, I dislike drama. It clouds judgment and muddies the water.

5. Given that I believe in state resolution, almost everything I do or respond to drives action. If we have a meeting, something should come of that meeting (an action, a resolution, a decision). A "go away and think about it meeting" does have a place. This is the exception rather than the norm, (at least for me.)

6. I believe strongly in the definition of success. If I understand that definition, I can normally figure out a route to success. Without that definition, I struggle.

7. I believe engineering should reserve creativity for areas where we can differentiate or where we have a core competency. Frankly, there are thousands of ways to track bugs, build project schedules, allocate resources and manage the software development life cycle. At the end of the day, I care little about any one methodology. I care most that the methodology is constant so we don't have to invent anything (from a process standpoint) and so we can put our talents towards a sweet configuration or software package.

8. I sometimes speak in black and white terms. I do this not because I am not capable of nuance but rather because this helps formulate or frame the argument. It goes to state resolution and execution. Nuance is critical for success. Plain speaking and bullet statements cause you to refine your argument and that drives state resolution. 

So, anyway, it was a good discussion and this was something I shared with the team. Do you have tips for managing yourself? What are some of your maxims?