Some 20 years ago I worked at a startup with a CEO who liked to cook up various tricks to make potential customers think we were further ahead than we were. I complained that he was setting us and the customers up for failure. I suggested that at the next meeting we should be completely open and honest about what they would buy into. We could leverage it, even. We could tell the customers about the big opportunity to be part of, and shape, our journey. Somewhat to my surprise, he agreed. And to his big surprise, the next meeting landed us our first contract. I was a bit disappointed that he then coined it “the trick of honesty”. I suspect he might still be regarding it as just one of his many tricks. ¯\(ツ)/¯
My former boss is far from the only one thinking like this. Rather, it’s quite common. In the field of career advice many gurus encourage us to “fake it till we make it”.
Someone: “Give me your best tips for applying for this job opening, folks. They ask for X and I am not sure I have all that much of that.”
A crowd of advisors: “Fake it and show em’ on the job that they hired the right person!”
I think not! Say you land a job on those premises. You now face a new problem: They think they have hired someone else, with different skills and experiences. This is a really bad start to a relationship. You’re now an impostor, and not just suffering from the syndrome.
Instead, set yourself up for success by being honest. It’s my experience that you sometimes land the job even when voicing some doubts about this or that requirement. Recruitment job descriptions can be a bit of a wish list, and the people hiring might find that you bring enough other qualities to compensate for whatever it is you express concerns about.
Deception is never a good foundation for teamwork. Why, then, is this such common advice? It was a disappointment to discover that a favourite book of mine, The Pragmatic Programmer, is a source of such tips! In the opening chapter of the book (how could I have missed it before?!) we are instructed to take a cue from a story about some soldiers cooking stone soup to lure villagers to share their food with them. The parable is used as a metaphor for situations like:
We want to instigate some bigger change.
We anticipate that the organisation will not want to do it at all, or will subject it to layers of bureaucracy.
According to the book we should then make the equivalent of a stone soup and lure our team on the journey towards the change.
I find this recommendation troubling.
It is dishonest. I think you owe it to your team (and yourself) to be someone who people rightly can trust. Don’t manipulate others. It is disrespectful.
It is also counterproductive, non-pragmatic, even. The organisation might have very good reasons to say no to the change, as well as to have bureaucracy around how changes enter the system. There is a cost to doing B, in that it means you do less of A. This alternative cost may well be worth it, but it is a cost that the team should incur with open eyes, cards on the table, and not be tricked into taking.
Don’t get me wrong. It should be fine to make a small proof of concept to investigate your idea for some change. If the experiment proves interesting to yourself and to your team, you can challenge the current plan together and make room for the change. What I object to is the deception. The stone soup is a lie.
What if it is not fine in your organisation to spend some significant part of your time experimenting with ideas, you wonder? How about, instead of tricking your teammates, you consider making this the hill you choose to die on? Work openly to convince the organisation to make room for experiments like these. Whether it is called 20% time, or cooldown, or hack weeks, or whatever. (I prefer it just being part of my job description, but that’s me.) Create an environment where people are supposed to cook up experiments, as well as expected to let themselves marvel at the experiments presented by their teammates. An environment where people do not need to deceive each other to get important things done.
When using dishonest methods you are putting something extremely valuable at risk: your trust. Don’t. You’ll need it for your long-term success and happiness.
Peter Strömberg 
Peter Strömberg is an autodidact programming nerd living in Stockholm, Sweden. He has been all over the (coder) place for a long time. After some 20 years in the profession he made an attempt to leave it for another passion of his: Product. That attempt ended when Peter was introduced to Clojure and he felt how it gave him back all the joy of programming, and then some.
You can contract Peter for remote Clojure/ClojureScript gigs up to 80% of an FTE. The other 20% Agical pays him to spend doing open source work. Most often this is about maintaining Calva, a popular Visual Studio Code Clojure IDE extension which Peter created 2018.
- E-mail: peter.stromberg@agical.se
- Twitter: @pappapez