There are no perfect solutions, there are always trade-offs. Expecting perfect solutions – checking all the boxes – is a common mistake projects and their sponsors make. One cannot have it all and have to give up on some of the requested features and functions.
Solutions to complex problems always involve trade-offs. There lies the challenge – among the different, less-than-perfect options, which one gives the most and compromises the least?
If you like this topic, you might be interested in listening to the episode – The short list – from Seth Godin’s podcast – Akimbo.
Not long ago I was leading a team of people on a months-long project with many work-streams and many more tasks. The tasks varied greatly in ways I have not thought about before and sparked the thoughts that went into this article.
Software engineers do their best work when the majority of the tasks are in line with the amount of ambiguity they accept and when the value of their work is in line with their expectations.
Value – the meaningfulness and impact of work – is a perception shaped by various factors. It is essential to differentiate between the value that work holds for the person and the potential value it may have for the business.
Ambiguity – the challenges and uncertainties a person may face at work – is a subjective experience, varying among individuals. Those with more experience and confidence navigate ambiguity easier, while others may attempt to avoid it.
Dissecting these two aspects of work along low to high ranges into four quadrants, each quadrant characterizes a type of work.
Grunt work is routine tasks requiring minimal decision-making or specialized expertise. Think of data entry, manual data validation, or repetitive administrative duties. Grunt work is essential for maintaining operational efficiency, but it can also be monotonous and disengaging for knowledge workers.
As engineer leads, it is crucial to minimize the impact of grunt work by automating processes and providing opportunities for skill development and growth.
Expert work requires deep domain knowledge, specialized skills, and a mastery of specific tools or technologies. Experts enjoy problem-solving and executing tasks with precision and efficiency.
As engineer leads, it is important to recognize and cultivate expertise within teams.
Conceptual work involves exploring abstract ideas, brainstorming possibilities, and conceptualizing new approaches. While the value may not be immediately apparent, conceptual work lays the foundation for future breakthroughs.
Engineer leads must create an environment that encourages experimentation, risk-taking, and out-of-the-box thinking.
Creative work involves pushing boundaries, challenging conventional thinking, and envisioning new possibilities. Creativity fuels innovation, enabling knowledge workers to think beyond existing frameworks and reimagine solutions.
Engineer leads must foster a culture that embraces creativity, encouraging diverse perspectives, and providing the freedom to explore uncharted territories.
Recognizing that individuals thrive in different quadrants of the ambiguity-value matrix is crucial in fostering a productive team. By understanding the specific type of tasks required for a project, engineer leads can compose efficient teams. It also enables individuals to perform at their best and maximize their contributions. Moreover, allowing team members to experiment and explore various quadrants of their choice promotes personal growth, stimulates innovation, and cultivates a sense of ownership and empowerment.
As engineers, we constantly grapple with the challenge of creating solutions that are efficient, scalable, and maintainable. A key aspect that can make or break our projects is the ability to establish a common understanding among team members. In any team, individuals possess varying mental models, skills, and experiences, leading them to arrive at different abstractions. These divergent abstractions may introduce misunderstandings and hinder effective collaboration. Abstraction serves as a bridge that enables team members to navigate the diverse mental models that shape their perceptions of concepts.
Each team member arrives to a different abstraction (A, B, C, D) from entirely different angles. The goal is to get everyone to arrive to a common abstract understanding (△). Use that to drive the conversation and problem solving, then approach the concrete solution (E) from the same starting point.
Example
Software architect working with a team of four on a complex problem. The four people think about the problem and the solution in different ways: (A) Component model diagram in LucidChart (B) Class model diagram using UML (C) Pseudo code (D) JavaScript playground on codepen.io
Led by the architect, eventually the team arrives to a common, abstract view (△) – a one-pager annotated diagram using C4 in Mermaid.
Team builds a web app (E) on the MEVN stack, arriving to the concrete implementation.
Conclusion
The ultimate goal of achieving a common abstract understanding is not to suppress individual creativity or to homogenize approaches. It creates a harmonious collaboration environment where everyone’s insights are valued and leveraged. Additionally, it fosters a sense of collective ownership and responsibility for the project. Rather than working in isolation, team members become invested in the overall success of the solution. It promotes clarity in requirements interpretation, reducing the likelihood of misunderstandings and rework.
The first digital note taking tool I remember using was GoldenSection Notes on Windows.
When I moved to Mac (2010) I looked for something similar and found SohoNotes.
Then came DevonThink, and DevonThink Pro soon followed. I used these for taking notes as well as keeping and organising documents.
Later Microsoft OneNote showed promise. I used it on both Mac and iPad. Sync between the two was mostly successful.
Along the way I also tried personal wikis – self hosted and managed.
A variety of markdown editors – distraction free (IAWriter) or otherwise.
Used mobile apps such as iOS Noteshelf and tried a bunch more.
I gave Evernote a shot, but that didn’t last long after losing notes due to a sync error early on.
Google Docs is still my go to editor for sharing and the rare occasions of concurrent editing.
I checked most online note taking tools as well – Notion, Roam, Bear, and a few more. I do not care for their mobile versions, I would rather have a solid desktop/laptop version.
For a while I used individual files tucked away in a directory synced to Dropbox. Most of my writing and notes were in rich text files (.rtf) at that time. I used and liked the Bean editor the most.
As of early 2021, I use Obsidian and I write everything in markdown. I still use DevonThink to keep documents organised.
Some work is not meant to be done quickly and not meant to be done by a specific date either.
It is not unreasonable to expect output and results in time to be able to progress, but slow work needs time.
Pin a deadline on or timebox an activity and be prepared to make trade offs.
Trade offs could mean less than ideal. Perhaps “less than ideal” is what’s needed for the work to be done.
Also…
'When will it be done' is an unanswerable question. However, 'what’s the probability of satisfying our strategic goals by this date at this cost' is both answerable and a reasonable ask as long as specific details of 'how' aren’t fixed.
— Allen Holub @allenholub.bsky.social (@allenholub) September 8, 2021
I have seen so many different responses from professionals when presented with a task.
No doubt every situation is different. There are cultural differences at the individual and organisation levels. There are many factors at play. However, over time the following characters emerge.
Wrong hire – “I don’t know. I have not been trained for this. Sorry cannot help.”
New starter – “I can take a look at it. Can somebody tell me what to do?”
Junior – “I do not know a lot. I can make a few recommendations to help. Can somebody review and let me know what else to do?”
Mid-level – “I am familiar with this. I will get started and check back for review. We can keep iterating until it is completed.”
Senior – “I have done/seen this before. I will have it done in a week. I will make you recommendations for the future.”
Leader – “My colleague is the best person for this. We will also help your teams to identify and complete these in the future.”
These are some of the examples of how I perceive seniority.
