Abstract:  Development managers often conceal the fact that not everything the team needs to know actually is known (or can be known), at the beginning of a development project.  This leads to poorly designed products and missed deadlines.  Stakeholders are let down and feel deceived.  Developers are punished for other people’s deceptions.  It’s better to state the unknowns, honestly, even if you lose face, because honesty and transparency are paramount and lead to better software development outcomes.

One of the more insidious problems, in development, is intellectual dishonesty.  An architect, or development manager (or team) will be selected to develop some software product, or other, and there will be a lot of the company’s success riding on the outcome of the project.  Everybody knows it’s important and that nobody must be seen to be “difficult” or impeding the project, for no good reason.  The temptation to simply present the development exercise as one of simple, routine execution, based on well-known certainties and a full and lucid understanding of the requirements is immense.  In other words, there is a great deal of expectation that the technical team pronounce the project as “easy” and to offer iron-clad guarantees on cost, feature set, quality and delivery dates.  These guarantees, if given so robustly at the beginning of the project, are almost certainly fictitious lies.

The problem is that if the project is truly worth doing, it will carry some unknowns and risks.  There is little point developing something that already exists, which can be bought, so for something new to be made, there will be things that the development team will have to research, experiment with and discover; maybe a lot of things.  An intellectually honest manager, or software architect, would acknowledge the scope of the unknowns, imagine the best and worst case scenarios and detail them.  Unfortunately, that’s often not what happens.

We all have different experiences and expertise.  Not a single one of us shares the same track record as our colleagues.  We’ve all come from different backgrounds, product developments and technology stacks.  We also all have different interests, as people.  Some care about the details, others are clear on the big picture business drivers.  Nobody can know it all, but the temptation is to pretend you do.  That is pure posturing and it’s ridiculous, because it puts the software project that the company’s fortunes depend on, in peril.  It comes from a deep seated insecurity and a fear of being let go, if you don’t appear to have everything in hand, under control and fully understood, all the time.

Key project stakeholders, also aware of how important the project is to the fortunes of the company, will exert extreme pressure on the technical staff to come up with dates, costs, scope and quality promises they can bank on.  That’s what they need.  Their belief that a technical person can actually give them those guarantees, based on an insufficiency of information, is naive at best and foolhardy at worst.  In some cases, the non-technical stakeholders are merely Teflon coating themselves, in the event that the project doesn’t meet its goals, which given the behaviour of the key stakeholders, it almost certainly won’t.  At that unhappy moment, they’ll be able to point to the technical guarantor of project outcomes and throw them under the proverbial bus.

The technical person often succumbs to the political pressure to pretend to know what all the answers are and what product features are required, or about the problem domain in detail, when they really don’t.  They’re trying to save face and to please the other stakeholders, when the truth is that they may not fully understand the customer requirements, the industry that the product sells into, the competitive landscape, the technology choices for this particular project, the abilities and limitations of their development team members, the peculiarities of the tools they will be permitted to work with and a thousand other variables that can drastically impact cost, delivery date, feature set and quality, no matter how agile the development method employed.

The thing about unknowns is that they inevitably assert themselves, during development.  If the technical staff member has been too keen to nail his reputation to the mast by making unbreakable, non-negotiable promises to the other stakeholders, then as soon as one of those unknowns goes in an inconvenient direction, for him, there is no way to rescue the product launch, the project budget, the reputation of his development team or the business from the disappointments that will arise.  A bloody and brutal death march will result, with developers whipped and flogged, almost literally, to “make up for lost time”, when the thing they were attempting was always going to take longer and cost more than the initial guesstimate promises made.

A good and seasoned development manager exposes what isn’t known, by the team, at the start of the development project and brings any new unknowns to the stakeholders, as they proceed.  They explain to other stakeholders not only what isn’t known, but what cannot be known and how long it will take (and what it will cost) to do the learning and research required to eliminate the unknowns.  This extra time and money needs to be baked into the project schedule and budget at the beginning.  In order to identify what isn’t known, though, some confession will need to take place.

The team members and management will need to be open and up front about what they do not know, even if that exposes a gap in their expertise or experience.  As I said before, not everybody can know everything and nobody knows it all, so stakeholders need to be realistic in acknowledging the team they have, while talented, always have some learning and research to do.  That’s just in the nature of making something brand new, which didn’t exist before.  You literally cannot hire a team of people that know all they need to know to do the job without stopping to learn new things.  If you can, it’s a warning sign that the product you are about to create has no unique selling point.  It has been done before.

Some company cultures posture in a stupid, macho way, belittling anybody that confesses to a need to learn something or to a gap in their knowledge or experience, but that’s a very stupid posture to take, given that it applies to all developers and their managers.  The reality is that people always need to climb learning curves, dig deeper into what they’re being asked to produce and learn about this particular market and customer base.  There really is no such thing as pure development.  It’s a myth.  Every development exercise carries some burden of necessary research.

Agile, as a development method, does not make the research part explicit.  Perhaps that’s why stakeholders think that any team which cannot execute on a product backlog and task backlog, mechanically and interchangeably, is a sign that the team members are incompetents.   If we don’t call out the need for individuals to learn as they develop, then the expectation is set that the job market is full of perfectly trained, fully formed developers that intuitively know everything about your product, customers, competitive landscape and market.  How could that possibly be, unless every developer in the world developed exactly the same products, for the same people, using the same technologies and tools?

These same stakeholders, who will deny funds for developer training, have an expectation that all other firms, in the world, pay generously for people to be trained, or else that the individual developer has so much spare cash and time, that they spend it all on personal training courses.

Take away the shame of being exposed as being without some (considered to be) vital skill, experience, understanding, tool, or piece of information and you open up the possibility of having looser, yet more realistic project budgets and schedules.  While you might not like the added apparent cost, you will like the added certainty that you can plan around a product release date more reliably and may even have time in hand, if things go well.

Once the development team members lose the fear of being called inadequate imposters and of exposing their relative skills gaps, the team can work better together, as a team.  Time can be allocated to go find out what each needs to know.  In some cases, the false economy of hiring junior programmers is revealed, when this step happens.  You realise that some team members need to learn a lot more than others.

Most importantly, team members no longer try to conceal trouble, when they encounter something they don’t know how to solve, or have an incomplete understanding of what they are supposed to be building.  The phrase I have heard used is: “Don’t sit on anything smelly.”  The spirit of this motto is to ask team members to expose unknowns and issues early, when something can be done about them.  The corollary to sitting on something smelly is that it just gets smellier and smellier.

When you transparently and honestly expose to stakeholders what the development team needs to go and find out, before they can set more accurate expectations on budget, delivery time, feature set and quality, you either get the support and permission necessary (what other choice do the stakeholders have?) or else the project is shut down.  People fear unemployment as much as they fear being found wanting in skills and knowledge, so the temptation to lie, to keep a non-viable project going, is strong.  However, the truth always comes out.

A non-viable project reveals itself to be so, at some point, so better to have the stakeholders understand this and make an active management decision, before all the gnashing and wailing, rather than letting the train wreck happen and have to live with the downstream consequences.  If the project is viable and worth doing, then it’s going to be worth getting the development team up to speed with what they need to know to develop it well.  If it’s not, the project should never have been started in the first place.  Too many stakeholders start non-viable projects, on a wing and prayer, with insufficiently deep pockets, and then blame the technical staff for not being able to pull off the required miracle.

It is the responsibility of every development manager and software architect to explain to stakeholders that nobody knows everything and that the people in their team were hired on the basis of being agile-minded enough to go find out.  It is unrealistic and dishonest in the extreme to expect developers to know everything particular to the stakeholders’ business and software code, straight off the street.  It’s time to stop play acting and making promises that nobody can keep.