Life, Teams, and Software Engineering

Month: March 2012

My Personal Manifesto

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.

First Real Test for Net Neutrality?

First, read this.

Is this the first instance of an access provider giving preferential treatment to data based solely on where it originates?  Is removing the limitation of an arbitrary bandwidth cap truly “preferential” or a legitimate business decision?

Now I admit that Comcast claims this is on their “internal networks” and so this is why it won’t count towards bandwidth limits, but I’m willing to bet that it costs the same to maintain the equipment it travels on no matter where the bits are coming or going.  I’m also willing to bet that the route the data follows is 99% the same as data coming from a service like Netflix on the “real internet” (granted with less “distance” to travel).

I’m sure their argument could still be made, however, but at the end of the day it’s a fine line.  What’s to stop them from standing up their own version of another bandwidth intensive service like Spotify, iTunes, Pinterest or Backblaze and giving preferential treatment to their version?  Granted, these hardly consume the bandwidth video streaming services like Netflix consume (as of today), but at what point does such a practice become anti-competitive?

I suppose since they’re not actively targeting traffic coming from a service like Netflix or Backblaze (e.g. through throttling or reduced quality of service) that they’re not really doing anything wrong?  But again, where is the line?

Either way, bad news for Netflix and possibly any other number of media streaming or bandwidth-heavy services.  Maybe Netflix should get with Verizon to open a similar door on their networks.

Safe to Fail

Failure

Many people have what I believe to be a misguided fear of failure.  Fear of public humiliation?  Losing your job?  Harming your reputation?  Perhaps you’re a perfectionist who thinks they can’t live with failure.  Fear can paralyze and hold back our most talented people and when they aren’t putting forth their most daring work due to fear of failure or the consequences thereof something must change.

In the software development space failure is usually defined quantitatively as being over budget, under featured, behind schedule, or qualitatively as having poor quality, or in some cases that it just doesn’t feel or work quite right.  The period of time over which these failures occur tend to be on the order of months or years, usually to the detriment of everyone involved.  But could this have been avoided?  Were the signs there all along?  Hopefully teams and organizations that encounter these types of long running failures have the courage to ask these questions, answer them, and act on the answers, but I suspect far too many do not.

The fact is that failure at some, and often many levels is unavoidable.  Once you realize this, you can accept it and embrace it.  That is what we all must do: stop fearing failure and embrace it.  However, as with anything there are responsible ways of going about this, and not so responsible ways.  Should we seek to fail from the beginning?  No, that’s not the point.  The point is to recognize some failure, however small, (e.g. this code didn’t work, the schedule slipped, Bob just quit, etc.) and learn from it.  An unrecognized or ignored failure means that not only have you failed, you just missed a growth opportunity and have truly wasted your time.

But how can we encourage giving our people the freedom and flexibility to bring daring ideas to life without burning everything to the ground and descending into bankruptcy and code cowboy anarchy?  If my thesis is that failure is worse if realized over a long time period, the logical thing would be to decrease the time window in which the failure occurs.  There are many things you can do to shorten this window without being overbearing or invasive in day-to-day work.

With Projects

Make sure you are capturing real-time stats of where your group is on your roadmap relative to where you think you should be.  This will allow you to have a constant pulse on the general direction of your work.  An example would be a burndown chart at the project level or a similar tracking method at the organizational level.  At the project level I’m a fan of the Greenhopper burndown chart format.

In such a format if you find yourself continually over the ‘guideline’ you will want to find out why.  Maybe the team is overoptimistic with their estimates?  Maybe the team is being so rosy because they feel the real estimates wouldn’t be accepted?  Maybe estimates are being advertised as commitments when they were never meant to be?  Maybe the team isn’t the one making the estimates?

Asking these questions will allow you to course-correct over shorter time periods while keeping everyone happy and well informed.  This frequent analysis and adjustment can help prevent long running failures.

Day-To-Day

Wouldn’t it be great if we could compress realized failures into a single day instead of over several months?  For many things we do as developers this can be done; we have the technology.

Be sure to set up productive development environments with super low friction using tools like Autotest or Watchr.  Tools like this allow you to automate your workflow using simple triggers (like saving a source file) to do things automatically that you would otherwise have to break your train of thought to do.  For example, I have my Watchr scripts set up to build the project, run the unit tests, and then for an embedded project, deploy the same unit test harness to a real device and run it there.  This type of low friction environment allows you to focus on what you’re really working on and most importantly gets you that feedback more quickly.  It might only be 10-15 seconds faster, but it adds up.

At a less technical level, if you don’t know the answer to something, ask, don’t guess. Turn to the person sitting next to you and ask.  If they don’t know, keep going until you find someone who does, even if that means contacting the customer.  Ideally the person sitting next to you is your customer, but that’s a different post.  Your customer is invested in this and you owe it to them to avoid speculation where possible.  The longer you wait to get an answer, the longer that assumption lives in your system, which can start the timer on a long running failure.

With People

Make sure that you instill a sense of purpose and pride into your teams from the beginning.  Make sure that they understand why your organization is in business and the significance of what they are working on.  They must feel like they belong and that they are contributing to something of value.  Empower them to really own their work and they will exceed your wildest expectations.  An environment like this is also likely to have lower turnover than the alternatives.

Above all, challenge them, but don’t break them.  Make sure your management knows their people, their abilities, and their limits.  Better yet, make sure your people know their own abilities and limits!  Then have them placed in a team a little above their current abilities but not beyond their limits.  Make sure they have team members who can and will act as teachers and mentors who can also help reduce that risk of long running failure.

With New Ideas

Make sure that ideas are received and evaluated on merit.  A good idea shouldn’t be overlooked simply because it came from the new guy, the old guy, or the guy with a new idea every day (enthusiasm!).  Most importantly, make sure that your people know that this is how these things will be handled.  Be active about it, prove that you’re willing to put your money where your mouth is.  Don’t just put out a suggestion box, you’re all in this together and your people want to be as big a part as they can.  Let them.

Encourage, but constrain exploration.  If these new ideas have merit, charge the person who proposed it with running it down.  Give them a couple weeks to flesh out the idea.  If they show progress, give them a couple more weeks.  If they don’t, maybe it still warrants more exploration, or maybe it gets killed dead.  Either way, two weeks lost is better than 6 months or years, you’ve all learned something, and hopefully grown a little in the process.  Ideas that show promise can can grow into a great new feature, new product, or totally new venture.  Left unknown and unevaluated it’s nothing more than a missed opportunity.

You could also constrain a new effort on budget.  I get the impression from Fred Wilson at Union Square Ventures that this is how they do it.  Start them with minimal funding on a truly ‘lean’ basis and fund them further when concept, production, and execution show positive signs.  I’m positive this is an oversimplification, but hopefully my point is made.  I’m sure that a welcome side-effect of this type of constrained environment is that the team (or company, as it would be) will know how to operate within these constraints should the need ever arise again (money isn’t infinite after all).

Have Courage!

In conclusion.  Have courage, put structure in place to recognize impending failure early, empower your people, and above all, learn from your mistakes.  Failure doesn’t have to mean that it’s over, just that you can do things better, and we can always do things better.

New Digs!

It’s been quite some time since I’ve done anything substantial with my blog so I decided to centralize all my web presence.  As I’m sure you’ve already noticed I have a totally new layout that should be more readable and more friendly overall.  You’ll also notice that we’re now at my domain, bakermatt.com.  That sure was a fun time with Blogger, let me tell you.

To my left I have my various ‘social networks’ listed with Github, Twitter, LinkedIn, etc.  Above I have some of my more useful projects listed as well as my resume 2.0 in various forms at re.vu and about.me.  I’ve also integrated Disqus for comments and overall conversation/social integration.  Way better than the built in Blogger comment engine.

I’ll have some more on topic content over the next couple days and hopefully I can gain some momentum with writing again.

Copyright © 2017 Life, Teams, and Software Engineering

Theme by Anders NorenUp ↑