Unintentional “lies” in the software development field?

Beware the Chicken-a-saurus!

Marketing folks have learned a few things from software developers.

It is funny to me that developers often speak of marketing professionals as if they mainly lie to people about what they want to hear (or as if that were a moral thing).

I say that because it sometimes happens in our industry as well… maybe more often than we want to admit.

80% complete

I remember when I was just getting started in software… senior developers would report their tasks being 80% done… and remaining 80% done for weeks afterwards.

On better projects, they would report 80% complete on their first status report, and then 85%, 90%, etc.

And some of them couldn’t tell me what the “method of successive approximations” was. Go figure.

“Ready to ship” in 3 months

Or how about another example – that the software will be ready to ship in “N” months? In a recent MarketingProfs short, “How to Sift Through Unintentional Lies”, it cautions marketers to brace themselves for “one lie after another”.

It is worth reading, not so much to raise your hackles, but to learn about the perception we create in customers in whom we want to build an assessment of value. Though the article speaks about other domains than software, here is a fragment related to us, from their perspective:

No development team wants to miss a deadline—but it will happen. “There’s one project I’ve been watching that has literally been three months away from shipping for 18 months now,” notes Anthony. You’ll get more reliable estimates if you eschew a single, long development cycle for rapid cycles that produce a “minimal viable product” for testing and further augmentation.

[Bold emphasis mine. Again, please read the article at the source reference I included in the preceding lines.]

So there you have it… marketers asking for agile delivery of value. That’s pretty cool and a good place for us to work together on rebuilding trust.

Notice the article is careful to say the development team is not being malicious or intentionally deceitful.

I cannot remember a case where we have been, either. Most developers I know love to write software. We love to create and we love to solve puzzles… but let me highlight a third example before we close for the day.

Trusting each other

Now, there are explicit promises and implicit promises. In fact, it is the implicit promises that can do the most damage. You can try to disavow them easily or you may not even realize others think you made them in the first place.

In this case, DON'T read the manuals!

Have you ever made a promise to a teammate that you intended to keep, but failed in the end to keep? I know I have.

Did you ever “break the build” or overwrite someone else’s changes because of a merge conflict? I have done that, too.

Have you willingly taken on some task for a long time, and then just decided not to do it because it wasn’t really yours to do? Did anyone depend on it getting done, and did they know you stopped doing it?

Did you know you’d made a promise, or acknowledge the breakdown you produced? Not always, for me.

Do you think that failing to notice that you made a promise in the first place makes it any easier on the person you let down?

These are situations we create with our own teammates… and yet we sometimes try to diminish the importance of the cost we produce for others in failing to hold the promises we make.

Keeping promises requires professional attention

Many people write about agile methods being based on a notion of trust (including me). Quick releases, adaptive requirements, continuous integration, better testing and quick communication can go a long way to help us make and keep promises.

There are many levels in a project in which we make promises. They all count, especially in the eyes of those who accept our promises.

Keep the ones to your customers, but also keep the ones to your teammates.

Think about this – You may be committed to the top thing or two on your list, and everything else gets shifted around and de-prioritized. Though it makes you feel better to tell others you are over-committed, you may really be over-promising and failing to commit to the promises you make.

What hurts others also hurts your identity with them.

About ken
Creative insights, passion and technical adrenaline - strategist, agile coach and marketer, providing a good life for wife of 20 years & 2 awesome teenagers!

6 Responses to Unintentional “lies” in the software development field?

  1. bfmooz says:

    Another great piece, Mr. Faw. I’ve contemplated this one many times myself. In moving from a previous manufacturing background to finance then ultimately to the technical world, it was funny how “fuzzy” the math became on identifying the status of a project. It was easy in a manufacturing field – I need to build X of these and I’ve already build Y or these…simple math. The technical field isn’t always that easy, but to some degree I’ve found that good project management skills help here. Both scenarios are about milestones. If we can identify those as early as possible and plug them into our project plan, it’s still simple math. Sure there are external factors that come into play, but the same is true in the manufacturing scenario too. What if the production lines goes down due to a faulty machine or a lack of parts?

    I think you really identified the biggest issue here in trust. If I have trust in my peers or my superiors and they in me, we can understand that something might only be 20% along that we hoped would be 50% along at this time marker and here are the factors why. Collectively learning a lesson makes us all better and more informed.

    And on top of that, I have this uncontrollable urge to call every pet store in the state in search of a chickenasaurus. Nothing solicits respect like walking one of those down the street.

  2. ken says:


    My daughter peeked over my shoulder and freaked out at the Chicken-a-saurus, so I know what you mean. Meanwhile, I have seen your puppy over on Google+, and it is not much to be afraid of.

    There are many posts to write about trust, from all sorts of angles. This one focused on promises and what they do to trust. How can we think of trust in each other if we don’t even know when we have broken promises? What does it mean to our teammates if we ignore internal promises and yet we drop everything to hold a customer promise?

    There are different kinds of promises, and not all are equal in terms of the consequences that they bear, positive or negative. But it is not wise to disrespect that we have made one, and just as important to learn to notice the implicit ones.

    (I’ll be in your neck of the woods next week… hopefully [for me] you haven’t found your new “pet” by then.)


  3. bfmooz says:

    I think you hit something here when you said “ignore internal promises”. To me this feels like a way of thinking versus a singular action. I think the key is when it becomes a pattern. We all know there are going to be instances where we just don’t meet commitments. Some things are just not controllable. But when it becomes a certain level of regularity, then it calls into question our integrity, our ethics, and our ability to be trustworthy.

    • ken says:

      Moose, I also see it as a way of thinking. The way we think shapes the way we act. If we know that nobody else can truly make a commitment for us, then the responsibility for being trustworthy rests squarely on our shoulders. We do fail, and the way we act when we fail either breaks trust further or reinforces our trustworthiness. All the places we have not noticed others’ depended on our implicit or internal promises we chip away at feelings of trust without knowing it.


  4. Pingback: Building trust with your customer « kenfaw.com

  5. Pingback: How do you manage demand effectively? « kenfaw.com

%d bloggers like this: