How to Motivate Your Development Team

Getting the most from your developers is a common management challenge.  Since executive management typically does not come from the development ranks, there is frequently a disconnect between what management thinks should motivate developers and what actually does.  In my experience, a very motivated developer is two to three times more productive than someone just going through the motions, so figuring this out is certainly worth the effort.

Here are a few tips:

  1. Nothing like Sales!! – If it is something you used to motivate your sales guys, don’t even think about trying it with developers!  If it involves clapping, ringing a gong, quotas, team building, or anything  above a 2 or 3 on the “cheese meter”, don’t do it!
  2. Involvement – developers are smart and they like people to tap into their smartness. Many companies use developers just as coders, however, not including them in the prerequisite processes of defining the target market and then figuring out the best product/features to address that market has a three-fold negative effect.  First, you are not leveraging some of the best brains in your organization to figure out what the market and product should be.  Secondly, you rob your developers of the opportunity to truly understand what they are to create and who it is to be created for.  And finally, you relegate your developers to just being coders which will make the great ones go look for a different job.
  3. Environment – development is just as much an art as it is a science.  And just as you can’t put an artist in a cube, in dress code, between the hours of 8 and 5 and tell them to create something brilliant, you can’t do that with developers.  Be flexible with schedule and dress code and get rid of the cubicles if you can.  If a developer works best at 1AM, go with that.  Keep in mind that interruptions significantly reduce productivity so keep non-development people away from them as much as possible and keep the meetings to a minimum.  One idea is to only allow meetings during specific “time windows” so there are large chunks of the day preserved for uninterrupted development.
  4. Contribution & Recognition – developers like to see the work they do make a difference and be recognized for it.  Just look at the open source movement – why would these developers spend so much time contributing to projects they will never make any money from?  Let them know how your product or service will change the world and then show them how what they did contributed to that.  Get quotes from a happy customer about how a new feature made their life easier and share that with the team.  Demo new product features in company meetings and recognize the developer(s) who did it – or better yet, let them demo it.

This is certainly not a comprehensive list, but hopefully it will give you some motivational insights that you didn’t have before.  The important thing to remember is that developers are motivated differently than anyone else in your company and that if you can do it well, the benefits are tremendous.


Am I Getting 100% From My Development Team?

A common question executives ask is whether they are getting everything they should from their Development organization.  Software development is often a mysterious and magic process to those outside the discipline and as such, is very difficult to quantify and evaluate.  The difference between an average team and a great team is huge (I am talking 10x!) so recognizing when things aren’t right and taking steps to make them right should be a top priority.

Here are 5 basic things to look for:

  1. Talent – every person on team doesn’t have to be a rock star but many of them should be!  Have you hired top notch people who were raved about by someone you trust?  Great engineers love what they do and likely develop for fun and/or have some kind of project on the side.  Are you consistently “wowed” by what these people come up with?  TIP: If you hired from Monster, chances are excellent you don’t have the talent you need.
  2. Transparency – Do you know what the Development team is working on and when it is supposed to be done?  Are there basic metrics in place? (development metrics to be covered in a future post)  Can you see how the team is progressing towards upcoming milestones?  There is no reason for Development to be a “black box” – executive management should have a clear picture of what is going on.
  3. Morale – is your Development team excited?  Do they get how what they are doing is changing the world?  Do they feel like they have the power to make a difference or are they just coders?  When a team is working right, there is a buzz that you can feel.  If it is dead quiet in the dev area, nobody arguing at whiteboards, and developers clocking out right at 5pm, you have a morale problem.
  4. Output – is there great stuff coming out of the process?  Are deliverables produced on time?  Do they hit the mark set by the Product Manager?  Are your customers happy with what they are getting or are they frustrated?
  5. Are you impressed? – A great Development team should consistently impress the hell out of management.  You should be thinking things like “how did they get that done so fast” and ” that new feature is really cool!”.  If that is not your consistent reaction, something is not working right

If you are now thinking that your team is not where it should be, don’t be too quick to start replacing people.  The problem may indeed lie with the individual team members or with the VP of Development, but just as likely, it may be with executive management.  I have seen several great teams that were unknowingly held down by the environment created by senior management.

We will talk about specific steps you can take to improve and/or unleash the potential of your Development team in a future post.

What Investors Want

If your company is planning to raise additional capital or working towards a liquidity event, there are specific things from the IT perspective the new investors will want to see and get comfortable with.  While some investors get into more detail than others, below are the most important and common things I have seen doing this over the past 10 years.

Not buying the current state

Most of the time, investors are not investing in or buying your company for what it is today.  They see the potential of what your company can become.  That potential might be achieved with just the money they are putting in or it might be with a new management team who they believe can take it to the next level.  From an IT perspective, showing that your current product and infrastructure can handle current volumes is not adequate.  It is critical to get an understanding of the revenue targets required to get the return they are looking for – from that, you can work backwards to determine rough volume targets.  It is these volumes that you need to demonstrate you can handle.

Wheels are not going to come off

Related to buying a “future state” of the company, investors want to know that as the changes are made from a sales and marketing perspective to ramp up sales, the wheels are not going to come off from a product and infrastructure perspective.  Investors want their money going towards new sales, not unexpectedly having to rebuild the product because it can’t handle the additional load.  It is OK to show the roadmap of things that need to happen to be able to support higher volumes.  Everything doesn’t have to be infinitely scaleable and fully featured on the day the transaction closes, but they want to know up front a ballpark cost on what it will take to get there.


For applications that house sensitive data (credit card data, health information, personal data, etc…), the investor’s money is at risk should that data be hacked resulting in either direct financial penalties or such bad press that the sales effort is significantly impacted.  Again, you don’t have to be perfect, but there needs to basic controls in place and a plan (with estimated costs) for what remains to be done.


Investors are not just betting on the market and the opportunity they see in that market – they are betting on the management team’s ability to execute.  From an IT perspective, they want to see a leader who understands where the company needs to go, can articulate a plan to get there, and is respected by those who work with and for him.  They want to see strong engineers who are motivated, excited about the company,  and have been around for a while – high turnover is an immediate red flag.

While there are certainly many more details associated with IT due diligence, these are the most important and most common things investors look at.   Don’t be afraid for investors to see that things are not perfect – they expect that.  What will derail the deal (or possibly require a leadership change) is if you don’t know what the problems are and don’t have a good idea of what it will take to fix them.

The Lean Startup Methodology

The Lean Startup Methodology.

The idea that you can apply Lean principles to how you build a startup is fascinating. A deliberate process to iterate your business – shortening the cycle time on trying new ideas and then failing quickly on ideas/approaches that don’t work.

A little more science and a little less art!

Local Optimization and Software Development

Local optimization (as defined in Lean terms) refers to working on making an individual step in the process as efficient as possible.  This is as opposed to working on the overall process.  This is common when there are multiple groups involved in delivering a product or service (as is the case for most products and services) – each group focuses on making their part of the process as efficient as possible but nobody is looking at the overall process as it is seen from the customer’s perspective.  This was illustrated for me very clearly with a recent interaction with Comcast.

All I wanted to do was to acquire a Comcast card for my new Tivo box.  Doesn’t seem like too big of a challenge, but apparently the service had not been switched over properly from my old address – shouldn’t be a problem, right??  Well… here is how it went.  The customer service person couldn’t figure it out so I am transferred to a technician, spent 45 minutes on the phone – he figured out the internet but couldn’t get the cable.  So, he had to escalate to somebody else who was supposed to get back to me, but didn’t.  I call back – 49 minutes of holding, giving serial numbers, unplugging, etc… and it finally starts working.  Then it stops working again!  Another call – this one 37 minutes.  Later that night the cable starts working.  Now that the service is transferred and working, I can call back to get the Tivo card.  Sure we can get that added to your account.  Great, when can you get it to me?  I am sorry sir, we don’t send those out, you have to go to a service center to pick it up.  OK, where is the closest service center?  Turns out it is 22 miles away!  OK, fine… can you please check to see if they have one before I drive all the way there.  No, we cannot call them.  Are you serious?  Yes.  OK, can you give me a number to call them?  No, they don’t accept calls.  Arrrggghhh!!!!

Each group that I spoke with (customer support, sales, tech support, and the service center) all had their optimized processes for getting me off the phone or out the door as quickly as possible.  Everybody I dealt with was polite and told me that they were sorry for my inconvenience and were going to help.  The end result to me was close to 2 hours on the phone and another 2.5 hours driving to and from the service center and waiting in the line there!

If we are not looking at the problem from the perspective of the customer, we are missing the entire point.  A software development organization that uses separate product, business analyst, coding, testing, and deployment teams is likely to solve the customer’s problem just as effectively as Comcast solved mine.  Agile product teams that include every skill needed to solve the customer’s problem quickly and effectively is a great way to avoid the local optimization trap.

“We are an Agile shop”… Really?

As I talk to software companies, many today will say that they are “an Agile shop”.  Really?  Just because you don’t have written specs and you have a list of things to do posted on the wall does not make you Agile.   Agile is a very well defined methodology derived from Lean Manufacturing principles pioneered by Toyota.  Some highlights of an Agile environment include:

  • Requirements defined in short “Stories” written from a business perspective
  • Product owners who are involved with the team daily answering questions and providing product direction
  • Estimates originated from the team
  • Short, iterative development cycles designed to produce working code that can drive customer feedback
  • QA involvement from the start!  Quality is built in – not inspected in
  • Automation – quick iterations and multiple releases require automated testing – there is not time for manual regression testing with every cycle
  • Velocity metrics and burn-down charts
  • Continuous improvement – with each iteration, you should be taking deliberate steps to see what is working, what is not, and coming up with actionable changes to make it better the next time around.

Moving to an Agile methodology is not easy and you don’t have to do all this at once, but you should certainly be moving in that direction.  If you are not, don’t say you are Agile – too many executives think that Agile is either an excuse from the dev team so they don’t have to write proper requirements or that it is a justification for management to change the requirements on a daily basis.   After all, we are agile!