Life, Teams, and Software Engineering

Category: leadership

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.

Safe to Fail


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.


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.

Quality is Not an Option

While I’m hardly the first to talk about the “Tradable Quality Hypothesis” hopefully I can reinforce in some of my readers (all 10 of you :) ) that Quality is not an option.  You cannot choose to lower quality (or forego quality producing/assurance practices) in an effort to get more features “done” or to deliver work more quickly.  At least not for any realistic amount of time.  If you do this, you might as well plan the rewrite into the schedule now.

So What if I Do?

Immediately, you will probably feel little consequence from omitting a few test environments or writing up those features without any unit tests.  But I promise it will catch up with you.  Failing to test (at any level), continuing to use outdated tools (without a transition plan), and knowingly adding functionality of little to no explicit value contribute to decaying codebases where bug counts and cost of change increase, while overall velocity (i.e. the rate of value addition) will decrease.  If you skip testing it now, guess what?  You’ll end up testing it a lot more when those bug reports start rolling in.

Yes, you might get to be a hero; and everyone loves a hero, right?  Maybe.  But when a situation arises where heroics are necessary (e.g. long nights & weekends) just to hit normal commitments teams should not celebrate.  That person has just set the precedent for what your clients and customers will expect of the team from this point forward.  Resist the urge to be a hero and be a member of the team.  Pull each other up as best you can to pull it in at the end, but be careful not to introduce large variances that can invalidate your velocity for that iteration.

If your team is delivering less and less because you’re trying to catch up with bug reports you may never be able to make up that time.  This can not only harm your organization’s reputation, but your personal or professional reputation as well.  Considering that, is it really worth the risk?

How to avoid the hole and dig out

There are many ways to avoid getting into the position of deciding to trade off quality for short-term schedule benefits.

One word: discipline.  Be vigilant that everything you contribute is tested in multiple ways (unit, integration, UI, etc.), have as many people as possible review your work and provide input, and make sure those things keep happening.  Yes it’s hard and can look to the uninitiated as if you’re moving more slowly, but when that thing you just wrote inevitably changes next week you’ll appreciate putting forth the extra effort.

Next is education.  Everyone should understand (though not necessarily intimately) what goes into delivering functionality.  Establish your definition of done and make it well known.  Hang it on the walls.  Recite it at the beginning of each daily standup.  I don’t care how people remember it, just that they do.  Whenever something is untested, it’s not really done yet.

If you’ve found yourself in this unenviable position, the first step is to admit that you have a problem.  Seriously.  We’re all proud of our solutions but sometimes they need cut down and replanted.  There’s no shame in it, I promise.  There’s only shame in voluntary insanity (doing the same thing over and over again and expecting different results).

Next, come up with a plan of how to tackle what is most commonly the real problem: technical debt.  Technical debt is any sub-par component of your entire solution space.  This could be anything from an inflexible test harness, to untestable or scary to change code, to relying on outdated or unsupported software packages.  If it causes you pain on or disappointment on the development side, it likely falls in here.  Environmental or issues external to the team should be raised to the team’s manager (e.g. Scrum Master) for them to deal with outside the team.  You need to identify and manage this technical debt before there is any hope of a sustainable pace of quality and value.

Don’t try to make it perfect, just make it better.  Don’t feel bad about it, what worked for a team of 5 and 100000 lines of code may just not scale to a larger team or codebase.  Our products grow and so our development support infrastructure must grow around them.

Remember, we’re the professionals

It may give the higher ups warm fuzzies to hear that it can all fit neatly into a little box, but no one will like the feeling later.  We do them no favors by making commitments we know we can never keep within any reasonable standard of long term success.  Clients can and should set constraints on delivery and tell us what they want delivered, but it’s our job to define how best to get there.  I don’t tell other professionals how to do their jobs when I pay for their services, and I would hope they would advise me on the consequences of taking shortcuts, while avoiding them completely.  That is after all, why I’m paying them.  They know better than I do.

If there are doubts about making commitments, or about quality, don’t be afraid to tell your clients (or your teammates) the truth, or at least what you observe.  That’s what you’re paid for, speak up.  Ultimately, even if the clients don’t say so, I’m sure if you asked whether or not you should test this feature you just gave them they’d be scared you even asked the question. Quality is always a requirement even if our clients don’t list it as a deliverable.

Copyright © 2017 Life, Teams, and Software Engineering

Theme by Anders NorenUp ↑