The Essentialist developer
I recently read a book titled “Essentialism: The Disciplined Pursuit of Less” by Greg McKeown, a brilliant essay on living better, and produce better results, by concentrating on what is really vital instead of trying to get every-redundant-thing done.
The book is absolutely brilliant, describing certain practices, like prioritising with care and eliminating the unnecessary, that are fundamental to everyone’s life.
But we’ll get to them in a bit.
For now, let’s start by focussing on the essentialist developer apprentice within a scenario we’re all so familiar with: there’s loads of internet stuff to do and every actor in the company wants their thing done first.
In this kind of situation, the essentialist has to be nothing more than a good lean practitioner (we’ll see that essentialists ♥ lean) and they don’t even start working — or better, estimating — if there isn’t a well-defined and unambiguous piece of work to do, with a definition of completion which is trivial to understand for everyone in the company.
Clarity of purpose is vital and to achieve that, communication has to do its job. Anyone involved (i.e. for a web team: developers, sys ops, product owners, UX, designers, QA, business stakeholders, marketing people, and probably many more) has to be informed and their advice is crucial in avoiding pointless “improvements” and taking bad turns. The essentialist’s fundamental task here is to ensure that everyone has a say and listens before taking any steps. There’s no rocket science here: a quick meeting where everyone is present at the same time, in the same space, can do the job.
During this process, I found new joiners’ contribution particularly important because of their freshness in the company rituals and naïve approach (that also means being closer to the final user), so never leave them silent and instead engage new ideas.
So, as usual, communication is the key. But how many times information spreading becomes repetitive, boring, unneeded, prosaic?
Listen
Being an essentialist engineer, developer, or designer means not much more than listening, connecting the dots, editing and coming out with what is the very best idea to invest time on that particular time.
It doesn’t mean over-communicating or arguing just for the sake of it. Just don’t speak until you have all the info: start listening to what is essential for all the actors in the story and find out what’s the best contribution the essentialist can add to the given scope. Do not speak too much and don’t talk just to impress. Don’t miss the lead. Try to look from different perspectives and approach different techniques. Listen to people in other areas to have a wider picture.
Don’t get everything done
Instead of asking “How can I do it all?”, the essentialist asks “What do we want to go big on?” — Greg McKeown
Going big on something means defining exactly what that something is. And it doesn’t have to be the piece of software we are creating. It means defining, together with {put your favourite stakeholder here}, what is the result we want to achieve in terms of benefit for the company/customers, and from there defining roles and duties.
Lean and Agile practices helped a lot on distributing product ownership, but I think that it’s now time to spend effort on focusing on getting just the very best from everyone, to avoid having unclear focus or multiple goals.
Software and web development is very complex stuff per se, and it’s easy to take decisions which are not clear to everyone. This can lead to the anti-essentialist diffused effort, which is one of the biggest problems in tech.
Diffused effort happens when everyone is focused on doing their little bit, a little progress in an indefinite direction, and everyone forget the real meaning of the thing as a whole. Or, even worse, when people improvise and act on decisions that shouldn’t really be theirs. What happens next is the need of added workforce to put everything together and focus on the original user requirement.
Being an essentialist means being the kind of person who knows what to not care and where to put effort.
The essentialists rejects the idea that we can fit it all in. — Greg McKeown
Maybe I’ve been a bit too generic here, but I guess that any of us has a story to tell about spending loads of time and not getting the return they had it pictured in mind — and of course a proportional return on investments or customer satisfaction.
Usually wrong turns like this can slip unseen in big companies, but they can just cost too much for smaller company or agencies. So, divide, excel ad conquer.
Learn to say “no”
As I said, it is definitely not an easy journey to become an essentialist. It requires attention, ability to distinguish the “trivial many” things that fill our days from the few “vital ones”, in life as in our daily work.
Once it becomes clear that almost nothing will be really worth your time, many of the requests you receive will have to get a polite but negative feedback from you.
This doesn’t necessarily mean putting down a “no” for everything, but maybe it can lead to different discussions:
- a suggestion for a rethink or a redesign
- a better proposal
- an honest “what should I rearrange in my priority list, then?”
- any other concise and sincere explanation for your turndown to keep doing what is your focus right now
Stop celebrating “yes” as a measure of knowledge.
Remember that if you don’t prioritise your own work, someone else will do it for you, typically without the attention you would put on that. Your “yes” is precious, use it sparingly.
Prepare
Benjamin Franklin, a proud essentialist, used to say:
By failing to prepare, you’re preparing to fail.
and I can’t agree more with him. Organising the work for a new task is like going out for a run or a drive: no plans mean losing all the joy†. First of all, we need a clear, essential, intent. If there is lack of purpose, people start playing politics and usually the scope widens up and the focus gets lost. Start drafting based on the company values to precisely define what’s the final purpose.
† well, actually going out for an unplanned drive can head to pleasant discoveries, but let’s focus on work for now.
After the design phase, then the preparation itself comes, which is made by stacked activities, having a clear and validated UX, removing any obstacles, identify the slowest/riskiest parts and discussing bad smells in the code base. And never forget to study what competitors do. Essentialist has to be the best in the market.
Always add time for unexpected during your sprint planning. If you’re not going to need it, you can use it for further optimisation and refactoring.
No preparation, no research, no competitor analysis, no internal communication, no learning, means no value.
Practice
The essentialist development can be seen from non-essentialists as organisation work for the majority of the time and coding for a fraction of it; this is not distant from the truth, but they are usually not considering that:
- The essentialist gets the best possible result for every assignment.
- The essentialist does not create nor tolerate any technical debt.
- The essentialist improves quality and accessibility.
- The essentialist embraces standards and loves open web.
- The essentialist reuses community-validated code and contributes to the open-source community.
In addition to those, the essentialist developer should also advocate and mentor all these practices, in order to activate synapses by making them spontaneous for the whole team.
On the contrary, if the team is applying anti-essentialist routines, the best way to pivot against them is to find exactly what triggers these bad routines and associate the trigger itself with an essential practice instead. Synapses will do the rest.
A final note on recruitment: beware of developers with CVs packed with programming languages and tools. Don’t take this the wrong side: it’s absolutely good to be curious and experimenting, but if you are looking for excellence, don’t forget that essentialism is more about specialisation than diffused knowledge.
What I’m going to say is probably unpopular, but I don’t believe in full-stack developers. I’ve seen the worst architectures of my life on Java developers’ hands, proudly writing CSS and Javascript code “because they could”. Again, excellence is found in people who are really into what they do — and maybe they blog about it, they are on StackOverflow, they contribute with some open-source experiments.
The interview process itself is ridiculously important for every company, so please never forget to make the right space for it. There’s no point in spending half a day in fixing an issue for dear old IE instead of preparing the interview for the next candidate who is going to join the company for the months to come. Find their strengths, listen to their needs and then picture them in the current team culture.
