Skip to main content

My work manifesto - the martial art of being effective at my job

My work patterns - the martial art of being effective at my job
Photo by Lukas from Pexels


Being effective at work is like a martial art. The difference between the novice and the master is often not the actual moves, nor the detailed sequence of their execution, but the efficiency, elegance, precision, and speed of delivery. There is no silver bullet, just radical common sense and a persistent drive to improve.

It is also true, that the same outcome may be achieved more elegantly with a different set or sequence of steps. Take for example typing. If you use two fingers, you may spend years practicing and perfecting your technique, however you will likely never achieve the same level of speed and perfection as if you had learned to type with ten fingers, and had spent your time perfecting those moves.

For most of my career I have worked in large matrix organizations. I have read and learned about work. I was trained. I have picked up best practices from colleagues. In this post I lay out a summary of some of the key patterns that I practice in my work every day.

Avoid letting email drive me

Email
Photo by Torsten Dettlaff from Pexels

You could argue, that my mailbox is a mess. I was an empty mailbox zealot for a long time, striving for a clean inbox every day. I was processing all incoming email, responding to them, taking actions, staying informed, archiving to folders, etc. My view has changed considerably over the years. No doubt this is partly because the volume of information I receive now far exceeds what I can process, but that is not the only reason.

I try my best to avoid letting email drive my day.

I scan my mailbox couple of times a day, running my eyes down the list of senders and subjects. Having skimmed through the emails I very well may conclude that neither of them are priorities at the time. I rather choose the topics I need to focus based on my understanding of priorities, and not on who is shouting the loudest, or who sent the most recent email. Once I know the topics I want to work on, I search my mailbox for emails on those topics. I deal with topics in batches, picking up all the emails in a thread and reading them in one go, instead of the constant interruption of a new emails.

I set annual, quarterly, monthly, weekly and daily targets. When I feel overwhelmed I open up a mind map (more recently Roam) and create a brain dump of issues on my mind. I sort, organize and rank this list based on priority, urgency, and my level of interest. I call these lists re-focus lists. I then convert the re-focus list into a checklist and start to tick items off in order of priority. This process eases my mind, since I have reviewed what needs to be done and have made a deliberate choice about what I will deal with first and what I will deal with last - or never.

Every one or two months, I take emails older than a certain date and put them in a special category: emails never read. I don't delete these, because who knows, someone might follow up on one I've missed, and people may get offended if they learn that I have deleted their email without ever reading it.

Always assume good intent

I assume the best of intentions of all my colleagues. I simply do not believe that apart from the extreme outliers there is a sizeable group of people coming to work with the intention of deliberately trying to be difficult just for the sake of causing trouble. At least not in the companies that I have worked in to date. It is my firm conviction that most people come to work to do something meaningful. I am yet to meet a person who is not.

In practice this means that when someone acts in an unexpected ("difficult") way, I ask why, and try to understand the situation from their perspective. I have made it a practice to avoid the terms "you are right" and "you are wrong". Instead I prefer saying "I have a similar view" and "I see it differently". I find that the mindset of "her view is different" is more productive then the mindset of "she is right because, she sees it the way I do; and he is wrong, because he doesn't.".

Maintain a transparent dialogue

I very firmly believe in the power of maintaining a dialogue. When I am not engaging with someone regularly, I automatically assume that our understanding is drifting apart.

Maybe there are companies that work differently, but in the ones I have had the honor to work in, I have found that relationships are always more effective then processes. The way I am able to build relationships is through an open and transparent dialogue about issues that matter to us both.

I am an engineer and an introvert. For me relationships do not come naturally. I would be comfortable working alone for weeks without the distraction of social interactions. The only way I've found to keep the dialogue rolling is by scheduling time and creating structures that facilitate this communication.

I try to keep meetings to a few participants only. My calendar is full of thirty minute one on one (1-1) meetings. Some of them are weekly, others bi-weekly, a few are monthly or quarterly. If there are urgent issues frequency can increase to daily or twice daily. I try to approach my meetings with the mindset of creating value for the other parties. I keep notes on discussion points and track actions and promises.

If something is not going well I don't hide it. People will eventually find out anyway. It is far better to report myself, then have the other party find out from someone else that something is not as we expected. I always strive to share bad news as quickly as possible, and ideally in a one on one setting. People don't like unpleasant surprises, especially not when others are there as well.

For staying in touch with my team I use 2x2x2 emails. These are essentially very brief status updates about what went well, what did not go well, and what is keeping me awake, sent at the end of every week to everyone on the team. You can read more about my approach in Pattern for staying connected with your team at work

Finally, in my experience a 5 minute phone call is always better then a 10 sentence email.

If I don't understand it, I cannot delegate it

If I don't understand it, I can't delegate it
Photo by Christina Morillo from Pexels

When I was first promoted to a management position I thought that delegation is simply about allocating responsibility and creating space for my team to deliver. While I think that those are definitely part of the game, I have learned that unless I have a good understanding of an issue and the solution I cannot successfully delegate it.

For this reason I do regular deep dives into issues, projects, and other topics. I happen to work in IT management. Digging deep for me involves reading specifications, reviewing process flows, looking at source code, understanding data, reading project plans, product backlogs, requirements matrices, test plans and test execution logs, operations documentation, incident tickets, etc. what ever it takes for me to get a hands on understanding of what is going on.

When asking someone to take on a responsibility I try to avoid asking "Do you understand?", since a "yes" will not tell me anything about the level of understanding. Instead what I like to ask is "What is the next step that you going to take?" or "Tell me your plan, how are you going to approach this?". The answer to these questions provide me with proof if we are talking about the same responsibility, or if there is a misunderstanding between us.

Deliver in short sprints

Grand visions and plans are important, but things actually get delivered in short sprints of efforts. I have found that put aside a few cases, most large projects have failed to deliver within originally planned time and budget. My approach is to break down large projects into simple next steps and get those delivered as fast as possible. I prefer this tactical approach and accept the risk that some things may need to be reworked or refactored later. I like to decide, act and course correct. In my experience it is rarely a good idea to wait for the perfect understanding, hoping to take the perfect decision.

I once heard the expression of doing dolphins instead of whales. This picture stuck with me. I believe more progress can be achieved with less overall effort - including the effort spent on rework and refactoring - via doing dolphins and avoiding doing whales.

Offer to take notes

Who ever has the pen has the power.

I prefer taking personal notes in meetings and to write meeting memos for the important meetings. I take notes simply because I forget what was agreed faster then I would like to admit - often by the end of the next meeting. I like to write meeting memos for key meetings, because the way the discussion and actions are worded give me power over the outcome of the meeting. Also I frequently find that however hard we try, some actions remain unclear after the meeting. By writing the minutes of meeting myself, I can ensure that the key actions get properly defined and assigned.

Writing the minutes of meeting, or taking notes in breakout sessions of workshops and offering to be the person to report out to the larger group will ensure that my points definitely get included in the larger group discussion as well.

Delivering ≠ not delivering + good excuse

I record promises and follow up on them. I aim to record actions and promises such that they surface in context. The key contexts for me are when the deadline approaches, when I meet the person, or when we have a meeting on the same subject again. For important promises I simply place a calendar placeholder in our agendas for the date of the deadline to review the results. I find this practice helpful for several reasons. One, it signals the person responsible that I am serious about the deadline. The meeting in his/her calendar will serve as a constant reminder. Second, it makes sure that I hold up my part of the bargain by demonstrating genuine interest in the result of the delivery.

When someone misses delivery I don't ask "Why?". Asking why focuses the discussion on understanding the "good excuse". By asking why, I will receive a list of excuses which I am really not interested in and which will not help us get closer to the solution. My first line of questioning focuses on the fact that the person has made a promise to me, which he/she has not honored. I believe we all want to be trustworthy, and part of that involves keeping our promises. My second line of questioning focuses on what the person is now going to do.

This is not to say I am not interested in root causes or in helping people overcome obstacles. However, my expectations is, when someone is committed to achieving a result promised, they should raise their hand the moment they run into blockers that they can't resolve, and not on the day when the promise is due. If flagged timely, obstacles can be solved, if raised on the day of delivery, obstacles are mere good excuses.

Look for partnership and avoid rivalry

Partnership
Photo by fauxels from Pexels

Finally I really dislike rivalry, especially rivalry within a team or between departments. I believe business is an infinite game and the objective of an infinite game is not to bring the play to an end by winning (or losing), but to find ways to keep the game running and to keep the players engaged. My primary concern is to deliver the best and most fit for purpose solutions I can, and not to keep looking over my shoulder and wasting time comparing myself to peers and being concerned about beating them in an assumed competition.

In practice this means that I really don't mind who brings the solution, as long as a solution is found. I look for strategies that define the future not in terms of beating the other party, but in absolute terms of achieving outstanding outcome.

Like this post?
Show your support.

Comments

Popular posts from this blog

Showcasing Excalidraw

Conor ( @Conaw ) pointed me to Excalidraw last week, and I was blown away by the tool and especially about the opportunities it opens up for  Roam Research ! It is a full-featured, embeddable sketching component ready for web integration. This post will showcase key Excalidraw features and discusses some of the issues I still need to solve to complete its integration into Roam. I spent most of my free time during the week integrating Excalidraw into Roam. This article will introduce Excalidraw by showcasing its features.

Mind mapping with Excalidraw in Obsidian

Mind-mapping is a powerful tool. In this post I will show you how and when I mindmap with Excalidraw in Obsidian and why mindmapping is such a good tool for Personal Knowledge Management. Like this post? Show your support.

Evergreen Note on Note-taking Strategies and Their Practical Implementations

This is an evergreen note that I will be revisit regularly to develop a comprehensive list of note-taking approaches including their practical implementations in various software tools. This post will serve as an elaborate table of contents, including a brief introductory discussion on the importance of note-taking, followed by a high-level walkthrough of each method. Links to posts and videos with detailed examples and descriptions will follow over the coming weeks and months.

Deep Dive Into Roam's Data Structure - Why Roam is Much More Than a Note Taking App

Which are the longest paragraphs in your graph? Which pages did you edit or create last week? How many paragraphs of text do you have in your database in total? Which pages do you have under a given namesapece (e.g. meetings/)?

contact: info@zsolt.blog