I actually started this post back in August of 2010 under the title “What Values Drive Me?” but for some reason I never finished.  Perhaps this type of self-reflection would have been too much?  Either way, here is my meager attempt at explaining what drives me and the type of professional I try to be.  An instruction manual if you will.

The general format of these sections will define what type of X I strive to be.  I think the best way to discover this about myself is to flip it on its head and ask how I expect someone to deliver if I’m on the receiving end.  This will be a living post that I’ll come back and update every now and then I’ll note when I change something.

What type of professional do I want to be?

If I were paying someone else to do what I’m doing, how would I expect it to be done?

  • Take care – no shortcuts, no matter what the external pressures, even if I’m a bear about it.
  • To be kept in the loop – I’d like to be able to have a constant pulse on progress.  I expect to be able to get this feedback on demand, even if I have to bother the deliverer(s) to get it.
  • To be consulted when questions arise – I don’t want someone to get it wrong just because they didn’t ask.  Ask the question, the customer may not even have considered it.
  • To be told the truth, no matter how inconvenient – Bad news stinks, hidden bad news is worse, but it is what it is.  If you believe you’re not going to meet some date or some scope, tell the customer so they can evaluate how best to move forward.  Don’t deliberately under-promise in order to over-deliver.  It destroys your client’s ability to forecast future resources and projects.
  • To see progress not just on a chart or table, but really working – Charts are good, but they’re only part of the story.  If I can’t see some feature or functionality actually working did you really do anything?  This isn’t an unreasonable request.  Expect demos to be requested and be prepared to execute them.  Done means done, including being demonstrable.
  • If you say “done” or “complete” I expect it’s really done – “Code Complete” means nothing to me.  Is it usable?  Could I deploy it now?  Can someone who is not you pick it up and work on it?  Now?  6 months from now?  Get on the same page about what done really means, but if there is no agreed-upon definition, ask what you would expect if you were sitting where your client is.

What type of leader do I want to be?

How do I prefer to be led?
  • Lead by example, not command and control – If I expect other people to adopt practices or do things a certain way, I need to do it first and let them see the benefits.  Telling them to do it a particular way does not encourage them to understand the Why behind doing it that way.  “Just do it” isn’t encouraging, nothing can replace a good light bulb moment.
  • Expect greatness – Make sure people know they’re accountable for their work.  Encourage them to explore and grow within and beyond their skillsets.
  • Coach – make sure you can help people pick up good practices by coaching them when they need it.
  • Allow failure – failure is learning, learning is growth, just keep it in check and as short-lived as possible.
  • Encourage exploration – you don’t know everything, so let other team members discover new things to teach to you.
  • A Sense of Purpose – I need to believe in what I’m doing to stay motivated, so I want to give my team a sense of purpose to help drive them to do their best work.

What type of coach do I want to be?

If I were a team member who needed help with something, how would I expect to be coached?
  • One on one – This is really what coaching is all about.  If I’m to learn something well it should be one on one with someone who knows how to do it.
  • My hands on – If I were getting instruction I expect to be driving.  Let the other person drive when you’re teaching them and talk them through it.  Let them reason it out, don’t just do it for them or whip up an example and expect them to be able to follow what you’re doing.
  • Let others fix their issues – This is similar to the last one, but important enough to highlight on its own.  As a team lead it’s really tempting to just dive in and fix everything for everyone else.  Don’t do this, it’s a trap!  If you’re reviewing code for another team member (especially a more junior team member), don’t just go into the code and fix it for them.  Present the comments and let them go on to fix them.  They’ll grow more this way, both technically and confidence-wise, and you’ll find that in the future you’ll have less and less to fix with their work.  If you just do it for them you’ll always be doing it and you’re ruining a growth opportunity for them.  Tools providing asynchronous code reviews like Crucible work very well for this.

What type of team member do I want to be?  

What do I expect from my teammates?

  • Keep things clean – Make sure you’re following best practices as established by the team.  This means tested, documented, well-factored.
  • Keep things working –  Keep the system building and the tests passing.  If you break it, fix it right away before doing anything else.
  • Keep others updated – Make sure people know what you’re working on.  This will keep the team from duplicating work and will keep things moving forward instead of sideways.
  • Admit when you need help – We all want to prove we can solve this problem, but sometimes you just need a different perspective.  It’s OK to ask for help, remember that we’re working as a team and not as a bunch of individuals on disparate parts of the same system. 
  • Step up, but don’t overdo it – Don’t burn yourself out and don’t work a ton of hours that your team isn’t working.  You’re worth more well rested, and working 12 hour days skews what the rest of the team appears to be delivering on.  If you work a bunch of extra hours and then stop, the team’s velocity will decline and your customer/client will wonder why delivery has slowed.  Normal means normal, don’t force the rest of your team to define normal as 10-12 hour days.

How am I best managed?

  • Expect me to keep you apprised of progress somehow.  Forcing me to provide this keeps it in my face and makes me ask whether or not what I’m working on is on track.
  • Tell me what that progress report should contain.  I’m a big fan of task boards and burndown charts since you can get as much or as little information as you want, but if there is some measure or detail of progress you need that I’m not providing then tell me.  I’ll figure out how to get it to you, but I can’t know you need it unless you tell me.
  • Get me access to the people I need to get questions answered, when they arise.  I don’t like making assumptions and I try to catch myself making them whenever I can, but I can’t remove assumptions unless I can get questions answered.  I don’t like stacking assumptions or questions up to ask at a weekly or monthly meeting with the customer/client since by then I’ve likely stacked other things in the system over top that assumption, so having access to them sooner (ideally immediately) is always better.
  • Give me leeway to explore new options.  I don’t want my relevancy or my ability to deliver quality to my clients to stagnate, so I don’t want my toolset to stagnate either.  Just because an organization has historically used one tool for some purpose for so long doesn’t mean that it applies equally well to all situations.
  • Keep me challenged.  I get bored, and when I get bored I start looking for other opportunities.  I don’t like to be idle with my career, my client’s money, or my organization’s resources.  If I’m not growing I’m wasting time.