New job, new mission statement

As I prepare to start a new job with a new company, I’m excited and nervous.  I love new challenges because I like improving stuff, and a new place is going to have opportunities for both of us to grow.  I’m just saying that I want to hit the ground running and make a difference. This is what I do with every new project.

Of course, I’ve learned that patience is required.  Nobody wants me to be a know-it-all who shows-up and starts running my mouth before I know which way is up. That isn’t me.  I want to quickly show value, but I know that I will make better accomplishments when I take some time to understand what I’m looking-at, before formulating any improvements. I learn more with my eyes and ears than I do with my mouth. That will take a few minutes (or days, etc.).

Steven Covey of course, recommends that you start out with some kind of strategy (in so many words). My initial mission statement goes like this:

  • Determine success factors: What do they want, and what could I do to add value?
  • Determine what my boss wants and what our customer wants. How do folks earn hero badges around here?
  • Determine what is in my scope and what is out. Watch my lanes. Be ready to help others if the opportunity arises.
  • Be transparent. I am human and I make mistakes. I will likely make a mistake or two. Take steps so I don’t make bad mistakes or make the same mistake twice. Earn trust by not leaving messes for others.
  • Always make backups and have backup plans. Perfect paranoia is perfect protection (in prod).  Safety first.
  • Try to plan ahead. Determine what others are doing, so I don’t interfere with their work.
  • Stow my ego. Never let it do the talking for me.
  • Immediately build my study-list and ramp-up on my homework schedule.
  • Determine which people are ninjas and which ones solve problems.  Determine how to get their time without interrupting them or wasting time.

That should do for now.  In one month, I will re-shuffle this list and build a more-permanent mission statement.

Posted in Career, Personal, Professionalism, Team | Tagged | Leave a comment

Reviewing your people

*Disclaimer: this is not about my employer. This is about all companies everywhere. *

If you are in charge of people, I guess you could either be the type of person who takes from people, or you could be the kind who invests in people.

I don’t want to seem over-dramatic here, about the “taker” kind, but imagine a boss who expects people to work and in-return, that person gets paid. It is a simple transaction. You are trading work for money. Some-day, if that person stops producing: boom, gone, just like that. No work = no money. “It’s just business”, I know, but it seems a little cold to me.

Let’s think about the other kind of boss, who invests in people. It goes like this: you work, and in-return you get a paycheck and some feedback about how you are doing, and suggestions for improvement. If you are under-performing, the boss gives you some advice about how to do better. Maybe you even get some encouragement to perform better (not in the form of a threat. Carrot, not whip).

No doubt, the investment scenario does take more time and effort, and maybe some of those investments don’t pay-off. However, a good boss can help you keep your job, and probably even get more value out of you.

NMFP, or should it be?

The first kind of boss will make it “your responsibility” to be productive and earn advancement. If you can’t think of a way to be more productive, then that is ultimately “your problem”. It is up-to you, to solve the situation, and if you can’t, then you are the one who suffers, not him.

The second kind of boss will make it “our responsibility”. Ultimately, it is his job to figure-out “the way it goes, around here” and help you understand it. If he is really good, he can explain how to figure it out for yourself, so you can learn the technique and eventually figure-out other things too. You might even become so good at it, that you can advise/supervise others, and pay-it-forward.

Hopefully, you can see that the 2nd boss, is the kind of guy that you want to have as a boss, or want to be-like. The first guy, is not really “on your team”. He is looking out for himself and isn’t really adding as much value as the second guy. In fact, think for a moment about what might happen someday, if something goes wrong for your project/team. Do you think he might “take-one-for-the-team”, or would he throw you under-the-bus? What incentives will guide him in this sort of decision?

Being The Guy

One of the best ways that you can “be” the better kind of boss, is to review your people. It might seem like you don’t really need the formality that goes along with an actual review.  You could just keep it simple: maybe give some advice, and leave it at that. Done. Right?  Well, that is exactly what I’m talking about. If you are the kind of boss who is going to cut a corner, find a shortcut, invest the minimum time or effort into his people, you will also be able to come-up-with an excuse why it doesn’t matter. Does it?

That is my whole point: Start by making it matter to you. Make that extra effort. Don’t just give some words, off the top of your head, and tell yourself that it is good enough.  You want your folks to go that extra mile, and put in some extra effort. You don’t want them settle for anything less than an “A”. Well, start by wanting that for yourself. Go that extra mile to encourage them. Help them figure out how to get an “A”. Be accountable to them.  Be accountable to yourself.

Plan your success. Write it down. Be formal. Demonstrate professionalism and extend effort that wasn’t necessary. Make it your business to help folks. Don’t just sit in the chair of a boss. Be the person who deserves the chair.

Posted in Career, Professionalism, Team | Tagged , , , , | Leave a comment

Support utilities

A few months back, during one of our meetings, a PM spoke-up with a good idea which would help another team.  The suggestion was to use one of our old utility apps called “shell and pay”.  Last year we used it for a high-pressure prod upgrade, to perform some quick, surgical tests. It worked like a charm and made it easy to find and troubleshoot a few small but evasive issues.  As you might have guessed by the name, it had something to do with getting paid. So of course the stakes were high.  Based on feedback, I guess you could say that it left a good impression on some pretty important folks.

When the manager suggestion the shell-and-pay app, it seemed to come out-of-the blue. This is because these two teams and projects were so different. It took a few minutes to figure out how it could be useful.  The answer was that the shell-and-pay app wasn’t exactly the right tool for the job, but nonetheless, the concept itself was sound.  Focused, precision tests can save people hours when it really matters, and that can add ubiquitous value, which is both easy to overlook and hard to forget.

When you don’t need a bigger hammer

The shell and pay app didn’t even start-out with this intention.  It really was just a launcher for another program (as the name implies).  The real payment piece contained a bunch of security stuff and information coordination between different teams and even different companies. The project turned into a metaphorical curvy road along the side of a cliff. The dozens of potential failure points were hard to anticipate or assess. When things went wrong, it was difficult to find the cause (think: security) and that was pretty frustrating. We didn’t need to circumvent security to get answers, we just needed different insight.

Early-on, the original app isolated one tough problem for us. It was great. It inspired my team to think-up a few other diagnostic tools. None of them were fancy. We always leaned towards keeping them minimal, so they would be cheap and simple to use. Of course this strategy has a few trade-offs. When we got a support-call with a payment problem, and one of the diagnostic tools could detect it, then the problem got solved quickly. Big ROI. If it didn’t detect the problem, no biggie, because the tool didn’t waste much time. New problems often became inspirations for new features or new utils. Time-lost on support and diagnostics declined steadily.

Lesson learned

Probably our most important lesson from all of this: take the time to make those utilities before an emergency happens.  We found the time to prepare, and if we didn’t have the time, we made the time anyway. It became that important.  There was no more debating about it, because it wasn’t just another feature (and therefore might be “in-scope” or “out-of-scope”). Diagnostic utilities were required, just like they were parts of the framework.

If you are implementing or supporting a system, there are opportunities for big ROI from developing mini support utilities to isolate and diagnose your problems.  It may not sound very elite, but when your mini ninja tools find the last needle in your haystack or avert a corporate apocalypse or something, you will seem like some sort of magician, and that feels very leet.

Posted in Errors, Lessons Learned, Maintenance | Tagged , | Leave a comment

Should I make a backup?

Every now and then, someone will ask me this, or I will ask myself this: Should I make a backup before I apply these changes?  Sometimes, it just doesn’t seem necessary. Right?

If you ever find yourself in this situation, please remember this advice:

If you have too many backups, that is an easy problem to solve.
If you have too-few backups, that is a much more difficult problem.

Please have an easy problem.

Commit this to memory and make the correct decision, should you ever face a moment of hesitation.

Posted in Lessons Learned, Professionalism | Tagged , , , | Leave a comment

When a process actually is a person

You’ve probably noticed that I talk a lot about processes. I often talk about how teams and departments need to have processes which are “not a person”. Mainly because processes can be designed to insulate against the flaws of people. Flawless people don’t exist and it is better to have processes that account for mistakes, anticipate them, and handle them gracefully.

Also, you’ve probably heard that some people have difficulty changing, especially if they cannot see a good reason to change. Freud would say that first, they have-to “want to change”. Nobody should have processes that are so-complicated that we need Freud, to explain them.

Okay, that philosophy stuff is nice and all, but what if you are working at a place where the process actually is a person?

I’ve seen a few places where the process “was a person”. By that, I mean that the entire process was dictated by a person, owned by that person and the process centered around that person and personality. It was a one-man-show. At each of those places, the person was not particularly interested in changing. After all, “if it ain’t broke, don’t fix it”. That person felt like they had it all figured-out and things were going as-smoothly-as-possible. You would NOT convince the person that the process was broken or had room for improvement. So just save your breath.

So, now what? If you can’t beat ‘em, join ‘em, maybe? Otherwise, should we pack-up and go somewhere else? No, of course not. When you find yourself in this situation, there are a few thing you can try.

When you are learning a new card game, how do you do it?

The concept here, is the same: You need to observe the process, learn how it works, and try to be successful within the limits of your environment. It will seem awkward at first, but if YOU are willing to change, then it doesn’t have to be very awkward for long.  You simply need to be dedicated enough to stick with it.

That is nice and all, except you are probably going to need some cooperation from the guy who “is the process”. After all, he is holding all of the cards. He might not feel particularly cooperative. In fact, he might even feel threatened. Like, you are implying that he isn’t doing a good job or something. Worse than that, you might be suspected of having plans to dethrone him, or take his mojo, or his cheese, or whatnot. If you do something to make this person seem threatened, then you will change this task from “daunting” to “impossible”.

The person is going to feel threatened to various degrees, no matter what you do or say.  My personal recommendation is that you make an ethical decision to NOT be an underhanded s-o-b who would shanghai a man and take his gold. Just don’t.  If you cannot commit to that path then you can probably stop reading now. Otherwise, if you have more-honor than that, and you are committed to taking the high road, then here is what you do.

This is when you need to remind folks that you are a good-guy. Both of you are. Be honest about your goals. Nobody is going to BS anyone here. We are all a little too smart for that to pay-off. Remind everyone that these processes need to be documented. They do. This inevitable and that day has come. Ultimately, this will be good for everyone because it is a chance for people and process to grow. The process and the person don’t need to outgrow each other, but a person and a process will always end-up limiting each other. It is a cage with golden bars. On the one hand, gold! Woo! Looks nice! But don’t forget it is a cage. That is never a good thing.

Next step: Observe, ask questions, take notes. If you see something that could be better, don’t discuss that now. After some time has gone-by and you understand more of the process, if you still think it could be improved, then ask questions about whether anyone has considered [good-idea]? Chances-are, you will get a response like “we tried it but it fell on deaf ears” or “there just isn’t time for that” or budget, or approval, or resources, etc. This is good, because it is an opportunity whose time has not yet come. Write it down on a “upcoming” list.

Little by little, you can learn the process, document it, and formulate a means to distribute it among members of a team. This won’t happen overnight, so be patient and focus on making steady progress. As you gain understanding of more of it, you will get a better feel for “how much is there?” which can give you some idea of how long until it is done.

One last thing: Be careful to avoid the pitfall of your predecessor, and fail to write-all-of-it-down. This is your one chance to resolve that problem, but only if you write it down in a coherent manner, and put it in location where it can be found. Once you cover that last (and most-important) step, then you free yourself from that golden jail cell, and we all become free.

Posted in Lessons Learned, Professionalism, Team | Leave a comment

Borrow my time machine

Let’s just say: what if I owned a time machine? But it isn’t the kind that will allow you or me to buy a lottery ticket or invest in the stock market or anything like that. It only allows a person to go back in time and affect any project that I’ve worked-on in my career, or yours. Think about any project where you struggled with the timeline. Then picture yourself going back and changing a few things. Wicked-cool, right?

Your mind starts racing.  Eventually it occurs to you: why have I been holding back?! Why didn’t I already use it to fix these projects already? I mean, like, people were losing their minds here and I could have prevented it, or rather, I could go back and prevent it right now, or whatever. Just do it already! Right?

Now, what if I told you that I already used it? I went back in time, and did the things that were necessary to fix them, but it didn’t work. In fact, I did it a dozen times and yet, nothing.

You see, the solution wasn’t to work more hours. I did that and it wasn’t enough. Adding hundreds or even thousands of my own hours didn’t fix a timeline or a project. I guess that could only mean one thing:  Hours must not be the problem or solution.

I didn’t just add hours to the project either. I looked at several other factors and guess what? I found the root cause. Yes. Not only that, while I was back in time, I had a talk with management about the problem, I explained the cause and the solution.

But wait! We still seem to have (or had) the same problem(s). That would mean that, knowing the solution and telling folks, didn’t fix the problem. But why not?   It was the root problem, and knew the future and I revealed the answer, and yet, the problem lingers and we didn’t get the problem solved? What gives?!

This is the problem behind the problem: I knew the problem and the solution, but I just couldn’t get through to the right folks. I talked and persuaded and said scary stuff and maybe even threatened to quit, but none of it worked. They didn’t budge. It’s almost like they didn’t believe me or something. So now we have our current situation.

Is that really a “them thing” or is that a “me thing”? We could say that this is “their fault” because they just wouldn’t listen, but also, my persuasion skills or mentoring or guidance or whatever, could also be a factor. Right? Is there anything that I could’ve done to get through to them? If there was, then guess what? I need to learn that! In fact, I need to get better at that. What if I became great at that?

If I honestly did know the answers (and not just my ego talking), and I couldn’t convince the right people, then I guess that is a root problem (too). So, what if I worked on being great at getting through to folks. And then folks listened and we changed what we were doing, and things went better and more efficiently, and then everything was completed on-time.

Steven Covey: “Start with the end in mind”

Guess what we just did? We uncovered the underlying path to success. And it starts with learning how to get through to someone. That is our time machine.  Feel free to use it any time.

You think I just tricked you. All I gave you is a play-on-words, or a metaphor. It is not like I own an actual time machine that I could lend you, or anything.  And yet, that is completely a moot point. Isn’t it? Because it won’t make a difference, if we go back in time, and yet are still unable to fix the real problem. Do you think that going back in time and donating a bunch of your time (for free) is a solution? Or even for pay? Then why didn’t you just work more hours, or rent the right people, when you had the time? The problem wasn’t time. The problem was that you didn’t make the right decisions, and you didn’t pick a timeline that was realistic (and therefore you could not meet).

And to continue our metaphor, picture yourself six months from now.  You borrow a time machine and you are transported back-in-time to today, right now. What will you do now, to make sure that your next project will be successful? If you think in these terms, then you have something which is every-bit as effective as a time machine. The only difference is that you can’t draw upon experience and hind-sight. However, you do have plenty of experience and hind-sight that you can draw-upon from previous projects. They can’t all be that different. Can they? You could use the lessons-learned from those projects to anticipate the kinds of things which will damage your schedule, and you can take measures to prevent them.  It is something that you do have, and you can use.

Oh, and more importantly, you can start working on your communication skills and your relationship with your manger(s). If you can’t already persuade them now, or you can’t get them to improve current practices, to increase your odds of success, then a time machine probably won’t make much of a difference.

Use what you already have and get good at it. It is probably more powerful than you give it credit.

Disclaimer: The intent here was not to call-out anyone.  It is meant as advice to other developers, project leaders, PMs & other tech folks.

Posted in IT Psychology, Lessons Learned, Methodology, Professionalism | Tagged , , , | Leave a comment

The awkwardness of Agilefall

I’m probably making up the word “agilefall”, but I’m probably not the first. You probably guessed that it is a mashup of “agile” and “waterfall”. I know that these two methodologies are sometimes melded, to varying degrees. When you do it properly, they usually call it something different. I’m not talking about that. I’m talking about working on a project, using agile, and suddenly being switched to waterfall. It can be, um, awkward.

How Agile Goes

People who are using Agile will start with a general understanding of their entire project, but don’t wait for full details before beginning the work. The work is split-up into chunks (sprints). You identify the order of tasks and general scope of each sprint. So at the beginning, you should know how many sprints, and some expectation about timelines, etc. but you don’t have enough detail to carve it all into stone or anything. So folks don’t expect to have an accurate timeline or due-date, up-front.

One of the major differences between Agile and Waterfall, is that Agile has you concentrate on the work/detail for each sprint individually, as they occur. As the project progresses, you have (anticipated) opportunities to make adjustments along the way and maybe even change the scope and timeline to accommodate new information/details which are discovered. You don’t need to plan everything from the start, because your plan is to develop and improve the plan, over the course of the project. You are planning to plan.

This is nice, because you are allowed enough time to get it right, and people have a little more time to think-stuff-through, and make up their minds. Things are going to change, and you are counting on it. Hopefully, people will have their expectations set properly.

Waterfall, in a nutshell

In contrast, with waterfall, you plan everything up-front. You need supernatural powers or a time machine, so you can see into the future (possibly several years) and know every feature, every detail and every duration. Since this seems impossible, you always need to pad your timeline. When things don’t go as planned, folks usually hide the mistakes and scramble to make up the time before anyone notices. You never seem to pad the timeline enough and your timeline padding gets used-up way quicker than you anticipated. It is like the progression of a bad disease. It starts out with optimism, but just gets worse as it progresses and the project becomes more sick.

Intro to Agilefall

Agilefall is a whole different mess. So, imagine that you are working with folks who have done waterfall most of their careers. You are trying to help them make the transition to a more-healthy and realistic approach. They indicate that they are willing to try, I guess. So, you start coding and then at the end of sprint 1 you test (agile 101). This is when some (waterfall) folks seem to be caught off-guard. They see that you are testing already, so they instinctively think “Oh, testing already? So it must be all-done now. It seems impossible, that the whole project could completely be done already”. Right? They are still thinking like, “waterfall 101: after dev, comes testing, and then all-done, and ready for prod”. That is not how Agile works though.


Each sprint is like an inning in baseball. It ain’t over till it’s over. It seems pretty easy to grasp.  So you figured that folks could accept this new process and embrace it. But you may need to recondition the waterfall folks, to acclimate to how Agile works. Which means, reinforcing the message & processs a few times. Repeat after me: only one fraction of the project is done per sprint (and not the whole program). This is not the Boston marathon, it is a track meet. We will cross the finish-line every-single-lap, until we are done.

The more experience that your folks have with waterfall, the longer it will take for them to get used to something different. Which becomes less-fun at the end of each sprint. Don’t despair. Just be prepared to coach them through this awkward transition.

My point here is that change is hard. If “change” is not already your habit, then it is even harder. When you find a better-way to do things, it is going to invoke fear-of-the-unknown. You need to plan on that too. Keep an eye on the folks who are making a transition. Be ready to coach them a little (or a lot, maybe) and try to be supportive.  They’ll get there.

Posted in IT Horror Stories, IT Psychology, Lessons Learned, Methodology, Team | Tagged , , , , , , | Leave a comment