sents a journey. Both the service provider and the customer learn more and more about how they will achieve
success together as the journey progresses. This process
requires the consultant to rapidly learn the customer’s
needs and then adapt how the product may best fit those
needs. Failure to understand the customer’s true requirements before locking in the solution’s design will lead
to a constant state of flux with requirements constantly
changing. These constant shifts typically occur because
the requirements were taken in the context of a technical
challenge instead of a business need.
SORRY! DID THAT COME OUT WRONG?
When a product’s specification must be changed, there
is a calculated assessment by the product team about how
such a change will affect the product’s future commercial viability. A decision is usually made with some consideration of customers, but usually in terms of market
value. This process does not usually involve explaining
to a customer executive that they’re not going to get what
they have already promised their entire firm.
As the customer’s wants change into needs, a consultant must stay focused on dealing with the emotions of
the situation. There is equally as much human-to-human
communication required in this expectation adjustment
as there is in human-to-computer investigation into how
the impact of that adjustment can be minimized. Customers can be demanding and rightfully so in most cases,
but along with this comes an emotionally charged expectation to get what they believe they paid for. Hence, resetting that expectation must be dealt with carefully.
Hire too many developers as consultants and you
might find it challenging to have these conversations or
avoid them completely. This is one of the reasons project
teams try and restrict access that consulting teams have
with the customer. While this is well intentioned, the result distances the consultants who need to know the most
about a project’s requirements from the customer’s team
responsible for defining what they should be. The net result is misaligned or misunderstood expectations that can
increase the number of cycles it takes to finally get the
solution to an acceptable state.
ARE WE THERE YET?
Customers pay consultants to finish projects. Prod-
uct companies pay developers to continually improve a
product. We must recognize that consultants and devel-
opers have different modes of operation. A consultant
is focused on finishing a project before its funding is
exhausted. There is no guarantee of subsequent projects
as it’s unknown if the customer will want a phase two or
if their firm has another project for them to work on fol-
lowing successful completion of the first project. Each
project is an intense, but short lived focus.
I’m not suggesting developers don’t care about finishing projects, but consultants are forced to learn every project only has one shot at achieving. Consultants
learn the only good project is a “done” project. As such,
every consultant learns that each step along the project
path must be taken with care to minimize the chances of
missteps that will cause the project to backtrack.
IT’S NOT YOU, IT’S ME!
Developers love to develop. Consultants love to consult. Customers want to achieve a business outcome.
Hence, sometimes the repetitive nature of building the
same type of solution for yet another difficult customer
can be hard for a developer to enjoy. I’ve seen this in
action during software startups. The software engineers
that went into the field and made the product work with
the first few customers, have realized the need for configuration rather than customization. Repeated configuration can seem boring to a software engineer because
the technical challenge is no longer unique.
Conversely, consultants are trying to master the social challenge of project delivery. It’s an environment
where successful communication leads to less challenging development, not more. The enjoyable challenge
and the thrill of resolving it lie in different arenas for a
developer and a consultant. I strongly believe that one
of the keys to low attrition within a consulting team is
to not force a developer to operate as a consultant – as
doing so is just setting people up for a set of frustrating
challenges that they have no real interest in resolving.
Neither the role of the developer or the consultant
is better or worse. However, it is common for people who have become accustomed to performing one
of these roles to inevitably have trouble adjusting to
the other. This is because there are subtle differences
between the core skills required for success in each
realm. Our focus shouldn’t be to prevent developers
from becoming consultants, but to address the tradeoffs that occur when we do. If we can close these
gaps, then we greatly improve our chances of creating great consultants who are also great developers,
which is something we’d all be in favor of.
Shane Anastasi is the CEO of CirrusOne, the quote-to-cash consulting and implementation firm.