Productivity Series – Part #2 – The Best Outlook and Office Advice for Busy Managers

I am always wondering how many appointments the “average person” might have in his or her calendar. Whenever I look at new calendar apps, it seems that they have been built for people with 1 to 2 events per day, and about 5 to 8 per week. That’s definitely not what my calendar looks like – and the same is true for most of my colleagues in senior management positions.

In run a unit within the Vorwerk group which has about 350 individual contributors across different time zones – and for the last 6 months, I have also been responsible for another part of Vorwerk’s software engineering team in the United States. My calendar is in good shape (tidy, organized), but it is REALLY full of important things.

The same is true for my inbox. It’s not that I get lots of spam. I just get lots of email that is somewhere between good to know, important, very important, and highly urgent. I get it from lots of people inside and outside of the company, and it took my years to find a good way to create an organization systems that allows me to stay on top.

So, in order to fill the internet with more meaningless advice, I decided that I summarize by best tipps for organizing Outlook and Office as part of my blog series on Productivity – and maybe, some of the strategies are even useful to someone. This blog post will serve as Table of Contents for this special part of the series – here are some of the things that I have planned to show you:

  1. Organize E-Mail on Arrival with the “Holy Inbox” Concept
  2. Pin E-Mails from Top Contacts to the Top of the Inbox (only Outlook Web)
  3. Practice FRETMY or Use Notes for Incoming E-Mails (only for the web)
  4. The Sequence to Get Things Done: Read, Flag, Extract to ToDo, Follow Up
  5. Create “Linked” Notes with “Parallel Appointments” and Microsoft Outlook
    • For Meeting Notes (incl. Groups)
    • For Preparations
  6. Use Outlook’s “Calendar Board View” for Goals, Notes, Files & Links (web only)
  7. Use Outlook’s “Attachment View” to Find Things
    (more to come)

Productivity Series – Part #1 – Using GMail as Universal Inbox

I have been using GMail since its very first version, back in 2004. For several years, it was my email system of choice, until Google Inbox came along. That was like GMail 2.0 for me. But unfortunately, Google discontinued it some time ago, and so I moved on – to Office 365 (now Microsoft 365). Outlook is a good email solution – but it fails in various areas in which GMail worked for me, and so, GMail became something different for me: My Universal Inbox.

The concept of Universal Inboxes is quite well known from GTD, one of my life saver books. Although I reworked my productivity setup about 300 times over the last 15 years or so, many principles defined by David Allen still hold true. I am still maintaining what David calls a “Project” system (I call it “Topics & Workstreams” in my methodology), and the general concepts of “Inbox Zero”, “Next Action”, “Weekly Reviews” and many others are still at the core of my way of working.

So, how does GMail work as Universal Inbox? It’s as simple as it sounds – whatever happens, whatever I need to note down quickly, I just “post it” to my GMail Inbox. As I am (nearly) the only person still sending emails to that address, it’s not cluttering at all.

Once or twice per day, I run through my Universal Inbox, and with each item, I do one of the following things:

  • If it’s a task that I need to complete soon, I mark it with a star. That triggers my Zapier automation in the background, and creates a new todo item in Todoist. I keep the mail item in the inbox for review (weekly clean-up).
  • If it is something I needed to keep for reference, I forward or copy/paste the information to Evernote (using my personalized mail address for Evernote). I then archive the mail item, removing it from the GMail inbox.
  • If it is something I need to review at some point in the future, I typically make some comment regarding the when & why, by forwarding/replying that information to myself – this basically creates a new item in the email thread, and I technically created a personal note on the original email item. I then use the Snooze function go Mail, which postpones the whole thread to some point in the future, at which it appears again, including the information I attached to it.
  • I use the technique of forwarding/replying to myself (often called FRETMY by the pro’s, or “note to self” by noob’s) for many things – it’s a good (and in 99% the only) way to attach personal comments/notes to emails. I use FRETMY to remind me to work on documents (links to Dropbox, OneNote or GMail), or I use it for extending on a though that I had earlier. Funny enough, it is also covering 50% of all use cases for which I used “Note Taking” apps – because more often than not, notes are not being changed, they are just being amended (for “real” quick notes, I mostly use Apple Notes and/or Evernote). The only notes not remaining in GMail are notes that belong to a larger topics or work stream (called “Project” in GTD) – for that, I use another tool which I will share here in the future.

That’s my quick summary of how I use GMail as Universal Inbox (or “Unibox” as the pro’s like to say). In general, I found it to be a very good practice to separate my Unibox from my real email inbox (for which I am using Outlook with a different methodology) – it allows me to selectively use it, and not make every email important by default.

I hope my post was helpful for you – and maybe, you put it in your Unibox, with some FRETMY notes attached to it.

It’s 2020 – how is that even possible?! (To: Microsoft & Google)

(Photo by Markus Spiske on Unsplash)

Dear Microsoft, Dear Google,

How is it possible, that we have 2020, and there is STILL NO GOOD WAY to add privat comments or notes on emails? I mean, the most basic thing in the world, attaching notes to something you are working on (like a post-it on a letter just opened), is not available from the biggest “productivity” providers in the world.

Yes, hey.com has it – like it has tons of great features which all email providers should have. But it looks like a cartoon or a tool for kids, and it doesn’t work for business emails. And maybe, great apps like Spark will implement it soon – I have some trust in them doing that. But what about the big players, especially Outlook and GMail?

For 20 years, I am now forwarding email to myself, in order to attach a note to it – a feature that works because Outlook and GMail allow email threads, so my own email shows up below the original one. But of course that has one gigantic drawback: I cannot change the note anymore! I still need to send another email if I want to jot something different down. And even this trick seems to be unknown to 99% of all email users, because I see them constantly google’ing for that feature.

Sure, in Outlook and GMail, you can create tons of things “out of” emails – like Keep notes, or OneNote pages, or ToDo’s. But, and I cannot believe that I am saying that for like 1.000 years now, WHY IS THERE NOT CONSTANT LINK? I mean, how am I supposed to remember that I “created something out of an email” when there is no indication at the email itself? Not even an icon? Com’on…

So what do I do? I create a note “out of” an email, and I – again – forward the email to myself, attaching the link to the note (Outlook, Keep, Evernote, whatever…). In 2020!

Needless to say that this feature would also help small & medium businesses, who still use email as the main way of interacting with their customers. For them, CRM is mostly just that – attaching a few notes to an email in the one account all sales/service people are using jointly.

So, here is my last attempt: Dear Microsoft, Dear Google. I have a great idea. It is as stupid as bringing radio to the internet. It’s overdue for 30 years. And I hope that you FINALLY build it. Please – PLEASE – allow us to attach notes and/or comments to emails. Thanks!

All the best,
Julius

Did Apple just kill the Mac as the go-to machine for cloud developers?

And if not, will the move to ARM encourage coders who love macOS to go “serverless” (incl. FaaS) even faster?

I am a real Mac fan. I haven’t always been. I came to be over time. First, for simple things like personal use. Afterwards as productivity machine. And over the last 5 years or so, I even switched my (mostly prototyping) development efforts slowly from Linux to the Mac – only .NET (Core) and Azure coding remained the prerogative of Windows 10.

Now, Apple is moving the Mac to ARM. This has some exciting aspects: Much better hardware/software integration for native apps, for example. Interchangeable code between iOS, iPadOS, and macOS. Probably much better battery life. And likely an even tighter integration of “Apple-style” productivity – things like handoff and sidecar, which I admire.

However, there is also a downside. And it’s a big one. In my team, many people use Intel-Macs for software development, targeting our web and cloud platforms. Of course, the world is moving step-by-step towards “serverless” (at least modern organizations do), but major workloads are still based on VMs and Docker. And VMs and Docker are based on Intel/AMD technology stacks – in many ways.

X86 and X64 platforms provide many virtualization techniques even on the CPU level (especially Typ 2 virtualization). As such, they use native hardware to “provide” to their VMs. For Docker, the situation is similar: In Docker, Kernel-level isolation is used to run dedicated containers, but because Kernels are hardware-specific, Docker is not providing any level of abstraction. In other words: If you put ARM chips in your Mac, and there is no magic X64 translation in either the chip (which could be okay in terms of performance theoretically) or in the OS (which will probably never be “fast” at all), every hypervisor and container stack is limited to provide ARM-based operating systems.

How bad is it? Well, pretty bad. If the base of web and cloud technology on the VM / container level (and very likely also in the serverless-world, actually) will remain X86 / X64 when it comes to the metal underneath, the code you intend to build for those platforms…

a) will not run on macOS in the beginning anymore.
b) might run in a sub-optimal way at some point in the near future.
c) will never be a real 1:1 reproduction of your production environment.

That’s really sad. It means that for serious developers, many of the great tools that are (finally) available on the Mac platform (Atom.io, VSCode, Docker, Vagrant, GitHub, etc.) now have a at least a question mark attached to it. Of course, you can natively run code (Python, Node.JS, Ruby, etc.) on macOS for ARM – no problem. And of course tools like Docker and Parallels (maybe even VMware, although they have been awfully quite so far) will continue to run dev containers/machines locally with the right execution environments inside (many Linux systems support ARM – question is on which level).

But those local developer stacks will in fact be different from your production environments (unless you run ARM servers in the cloud) – and it is highly questionable whether the images you are using on ARM can “reproduce” exactly the same results that your DevOps pipeline and your cloud systems yield.

In the end, it means that the next level of abstraction – again – is immanent. If “code” is the real value, all that OS/kernel-level plumbing (which my teams have to do, because it generates quite a lot of value at the moment) has to become less and less important eventually.

With VMs and docker, we unified the local and server-side development, and for many years, that sounded like we finally solved that fu**ing problem of “runs on my machine”. In fact, VMs and Docker delivered the next level of what the JVM and .NET (Core) tried to do: To provide a universal level of abstraction for developers, regardless of the actual environment.
That was possible, because we went back to the lowest possible level (CPU/OS/Kernel) as common denominator, and made it work “side-by-side” with the fantastic and individual desktop experiences we all enjoy. However, now Apple is changing that denominator – and that makes it at least difficult for Macs to remain part of the “let’s code for the (X86/X64) cloud”-team.

My hope is that we further embrace “code” as the true common denominator. Again, the JVM and .NET (Core) tried to do that, and neither has given up yet. But in the end, it seems to me that “serverless” is the only real path towards a higher level of value generation in the long term, because it promises that you don’t have to build something for the cloud you are using – instead, the cloud provides everything to execute your individual developer stack. But for sure, we are not there yet – as of today, while “serverless” platforms and especially the big FaaS providers take away a lot of complexity from the DevOps teams, they also take away a lot of power and freedom.

Now, what does it mean for the Mac? I honestly believe that quite a few developers will switch to alternatives for at least some time – unless they build for iOS, iPadOS, or macOS, of course.
Cloud developers will move to either Linux (if they build stuff for AWS, Google Cloud, Heroku, etc.) or Windows (if they build stuff for Azure), and it will take some time before they come back – either because the VM/container situation is improving, or because they went serverless.

So, what’s the answer to the question I raised in the beginning? Did Apple just kill the Mac as the go-to machine for cloud developers? And if not, will the move to ARM encourage coders (on macOS) to go “serverless” even faster?

I believe, for some of us, the answer to both questions will be:
Probably yes.

D3BTOR – An agile approach to managing complexity in large software programs

Large software initiatives are among the most complex constructs to handle in many areas: Project management, architecture, team culture, release coordination, system integration, and many other aspects that lead to constant friction. This article introduces an approach to handle these kinds of challenges, by matching the complexity level of the solution to the complexity level of the problem.

Before we begin, however, I would like to point out that the thoughts and approaches in this article are not new – in fact, they were invented by companies like Spotify, elaborated as part of large-scale agile frameworks (such as SAFe and DAD), and many capable consultants teach variances of these processes all over the world every day.

That being said, each organization has to find its own approach to handling complexity – by selectively using, tailoring, integrating, and constantly evolving their way of delivery digital results. This is our approach: The “D3BTOR” team.

Let’s start by explaining what “D3BTOR” actually stands for. First, it is a list of “specialist skills” needed in every successful vertically integrated, cross-functional team: Definition, Design, Development, Build Pipeline, Test, Operational Readiness, and Release Coordination.

But what does that mean? And how does it work? Before we explain that in greater detail, we take a look at the big picture:

E2E DEBTOR

Of course, there are many concepts in this picture that need explanation.

We start at the upper right corner, right where it says “P2”. The angle we are looking at here, going from the upper right side to the lower left side, is called the “product & project perspective”. Projects are temporary initiatives (meaning, with a defined start and end-date) that deliver a specific outcome or product within defined tolerances. In our context, we are using the “PRINCE2 Agile” methodology as governance framework (and it’s “bigger brother” MSP for the overarching program structure) for all our projects. PRINCE2 Agile provides a lot of things to make sure that there is a chance to deliver a successful project. Among these things, the most important one is the business justification – without it, there should not be a project. But more about that later.

On the next level of the “product & project perspective”, going further from the upper right side to the lower left side, we find two examples for something called an “Epic”. Epics are actually well understood and clearly defined in many iterative, incremental, and agile methodologies (see the SAFe explanation), so we will not spend a great deal defining them here. Briefly described, Epics are high-level initiatives, outlining goals to be reached by the project that is responsible for their implementation.

The third level on the “project perspective” is composed of several plus signs (“+”), as well as some triangles (“Δ”). The “+” signs symbol so called “Feature Teams”, while the “Δ” is labeled “Foundation Teams”. We will explore these things in more detail in a later post.

Must-Reads for Managers in the 21st Century

Despite many similarities to “normal” craftsmanship, Management is a very special field of knowledge. It primarily deals with the effectiveness and efficiency of working with people, and being responsible for the results these people produce. Yet, despite thousands of books (of which I assume I read probably more than 100), the “one way” to do it right is probably wishful thinking.

Having said that, there is a lot of things to learn out there and we can see that in fact managers become indeed more effective and efficient by studying them. This is my personal list of absolute “must-reads” for managers (especially managers working on digital products or in the software industry):

  • What Makes Great Leaders Great (by Frank Arnold): If I could only recommend one single book on management, this would probably be it. First published in german (“Management – Von den Besten lernen…”), Frank Arnold has made a remarkable job to collect the essence of management wisdom in an interesting, yet powerful format.
  • Management 3.0 (by Jurgen Appelo): While the title of this book is complete crap (and frankly, I wouldn’t have bought it under normal circumstances), it is actually one of the best books about managing software development teams. Without going into too much details, the book explains many principles and practices of modern management, focused on handling the complexity that is created by setting up a team of humans. Great read, despite the title.
  • Managing – Performing – Living (by Fredmund Malik): Malik is indeed one of the best management thinkers of our time. Having been in several of his seminars, I admire the way he has assembled knowledge and presents it in a very clear and concise way. His book (also published first in German) has just been released in a new edition, and while I sometimes think he could be a little bit more humble in interviews instead of always expressing that he knew many things a along, I have to admit: In regards to many topics around management, he actually nailed it.
  • Making It All Work (by David Allen): While many people swear on “Getting Things Done” (including myself), this book does not only include the GTD methodology, it goes even beyond that. Everyone should read GTD, however, for managers, that’s just not enough. Management is not only about one’s own effectiveness, it is also about giving priorities and direction to the people being managed – and that’s where Making It All Work brings a lot of tools and insights.
  • Making Things Happen (by Scott Berkun): Who would have thought that the first book I ever read about Project Management would remain one of – if not the – best I would ever touch. Making Things Happen is more or less the most practical book you can ever read about management – it avoids a lot of the mumbo jumbo that can be found in the “methodologies” and “get certified” literature (such as PRINCE2, PMP, IPMA, and so…). Of course these methodologies have their place, too, but if you really would like to learn how to actually do a project, you should read Scott’s book first.
  • The Courage to Lead (“Mut zur Führung” – an interview with Helmut Schmidt): Many books about leadership are written by people that studied great leaders. This book is an interview with one of the most respected German leaders of all times, former chancellor Helmut Schmidt. It’s not an interpretation of how managers and leaders worked and why they did it – these are the actual words by someone who led one of the most successful countries of the world for years in various government positions. Helmut Schmidt is a great man, an authority on statesmanship, a brilliant mind, and one of the few great leaders of our time.
  • The First 90 Days / Your Next Move (by Michael Watkins): It is true what Michael stated in many interviews – managing job transitions is one of the most neglected areas of management reality, training and literature – with the results that someone at McDonalds moving from making Hamburgers to selling them on the counter gets actually more training for his new assignment than the average “manager”. Unfortunately, it is also true that it is critical to get transitions right, because managers make transitions all the time (at least if they are successful). That’s where this book shines.
  • Manage It! (by Johanna Rothman): This is again a book much more focused on managing software projects than “other kinds of projects”. Nevertheless, it is one of the best books about iterative, incremental, emerging management in general. The human nature to “predict” things (and actually fail and fail again) is one of the biggest obstacles to modern, results-centric management approaches. Johanna explains the reasons for that, and provides the advice how to implement it.
  • The Back of the Napkin (by Dan Roam): Management is – among a few other things – about synchronizing people’s minds and providing direction. For nearly all people I know, visualization is a crucial ingredient in this process. Many managers have a tendency towards PowerPoint – and even worse, they often start there before thinking about what they actually want to put across. Unfortunately, artificial boundaries (like those imposed by Office software) have a very negative impact on creativity and clarity alike. Reading The Back of the Napkin helps managers to break free of these boundaries.
  • The 7 Habits of Highly Effective People (by Steven Covey): I know, I know, I know. It’s the book everyone recommends. And yes, the author was a mormon. And sure, the book is old. All of that is true… however, what is also true, is the fact that there are probably not many books of that caliber that provide indeed universal principles on how to deal with one’s own inner world as well as with the people that share our lives. It’s probably best if you read it yourself, and form your opinion afterwards.
  • How to Win Friends and Influence People (by Dale Carnegie): Another very old book, another really bad title, but also one of the most important books you will ever read. Manager (and other kinds of leaders) must help other people to achieve great things – that’s there job. However, there are many ways of doing that, all involving to have a lot of interactions with them. This book provides timeless (and I don’t say that lightly) guidance on how to approach them, how to treat them and how to form a productive relationship with them.
  • First, Break All the Rules (by Marcus Buckingham): While I said in the beginning of this post that there is no such thing as “the way” of doing management, there was (and hopefully no longer is) something like a universal “treat everyone equal” approach to management that poisoned the minds of a lot of people. This book is about what you should do instead: Treat everyone differently, and according to his/her personality, his/her strengths, his/her talents, and his/her unique way of “drive”.
  • Good to Great (by Jim Collins): While not all of the great companies in this book will last forever, Jim found a remarkable list of aspects that increase the odds of success – especially the “first who, then what” principle (although he is somehow omitting the “why”), as well as the hedgehog principle.
  • What Got You Here Won’t Get You There (by Marshall Goldsmith): We all are limited by the things we do unconsciously. So far, they haven’t hindered us in being successful – at least, that’s what we think. But maybe, they limit us now, so Marshall helps us to take a look.

That’s it (for now).

Managing People: Synchronization & Compatibility

Executives – meaning, professional workers with decision authority – face many challenges throughout their career. Hard assignments, huge projects, the need to deal with severe problems, and all of that in the context of corporate politics and complex personal relationships. In the end, it is very likely that they cannot accomplish anything without the support and service of other people – that is where Management and Leadership become the essence of success.

All conversations about these topics, and the countless articles and books can never replace many years of learning and practical experience – however, knowing some things upfront can make it easier. One of these things is to understand the underlying principles of shared values and team culture – or how I like to call it: The difference between Synchronization and Compatibility. Successfully leading and managing people depends very much on these two factors, but unfortunately, most teams don’t know about it. Actually, even those who apply this principle successfully often figure it out by accident. So, what does that mean and where is the difference?

Synchronization means that there is a strong congruence in the way people use their minds, hearts and hands. While that may sound a little bit philosophically, let me give you an example: Would you accept to work with (let alone depend on) someone who has a different interpretation of trust than you do? Would you give an important task to someone who has never shown your level of commitment? Would you ask someone for advice, or for his opinion, if his interpretation of the big picture would deviate significantly from yours? Or, to give a last example, would you share your fears / doubts with someone who defines confidentiality differently than you do?

You probably wouldn’t (provided that you know). Basic elements of human interaction (like those mentioned above, and maybe a few more) must be tightly synchronized between people that work closely together – if they are is disagreement about these important aspects, the work they are performing and the results they have to deliver will always remain below their potential. In a sense, if you take a famous and often cited model: You can only have people in your bus that satisfy these requirements.

So what are the things that I consider to be the baseline for synchronization in order to ensure that teams can be successful? Here is my initial list (yours might differ) – actually in no particular order:

  • Loyalty, Trust & Mutual Confidentiality
  • Giving and Receiving Appreciation
  • Humility and Recognition
  • Candor, Openess to Feedback & Level of Constructive Critisism
  • Initiative + True Commitment
  • Results-Orientation and Resilience
  • Quality Consciousness & Self-Demand
  • Ability and Receptiveness to Change
  • Responsibility / Accountability
  • Contribution to and Understanding of the Big Picture
  • Focus on Goals based on Common Objectives
  • Making Use of Strengths vs. Dealing with Weaknesses
  • Handling Mistakes and Errors
  • Satisfaction through Work
  • Pleasure of Achievements

On the other hand, people are different and that is not only great, but even important for better results and real successes. Actually, teams assembling different characters are known to perform much better than teams that are composed merely of clones. While I will not go into the reasons, there is one thing to point out: What is often forgotten is the fact that there needs to be a level of compatibility between these people – they need a way to deal with each other effectively (and if possible even efficiently). Experienced managers and leaders spend a lot of time to optimize the level of compatibility, for example by bringing in external advice and coaching, and by tailoring the assignments of people based on their strengths, learnings and feedback. Going back to the mental picture used before: In terms of compatibility, the second step is to get the right people in your bus into the right seats – and to understand that you should think very carefully before throwing them off the bus too early.

What are the things that need to be compatible within a well-performing team? One very common example is the so called leadership style. Of course every organization needs leaders at multiple levels and in multiple facets. What is important is that the ways of leading people – especially in matrix and network organizations – are compatible with each other, and of course also compatible with the individuals being exposed to them. However, note the distinguishing between synchronization and compatibility: The leadership style of different people can (and actually should) differ, as long as it is compatible and the synchronization on other aspects is given.

The same is true for things like decision making, the way people organize things, how they solve problems, their personal method of working, and how they deal with complexity. Actually, here the contradiction is that the level of difference might actually increase the likelihood of great results as long as the compatibility is ensured.

Of course, there is a nearly indefinite list of things that have to be compatible when working as a team – the importance is to understand that each team needs their own list. Consequently, I can only share my own list and the most significant topics on it – feel free to adjust and replace whatever feels right for you:

  • Leadership Style
  • Definition of Management
  • Communication and Information Exchange
  • Authority vs. Collaboration
  • Decision Making & Problem Solving
  • Measuring Progress and Results, as well as Exercising Control
  • Governance and Organization
  • Application of Methods and Tools
  • Professional Conduct and Necessary Competencies
  • Dealing with Complexity and Uncertainty
  • Defining / Planning vs. Executing vs. Learning / Feedback
  • Customer-Orientation and Stakeholder Engagement
  • (this is only a starting point and will differ from context to context)

The general approach to differentiate between synchronization and compatibility can also help to get a better grip on buzzwords like “culture” and “values” – because it differentiates clearly where culture includes or excludes people, and also where values must be strict and where they promote tolerance.

The One and Only Reason for Failure

There are certain statements about the job of a manager that can’t be repeated to often. Here are two of them: Under-promise and over-deliver -and- Clarify, clarify, clarify.

The reason for their importance is that mismanaged expectations are not only “one of many”, but even “the one and only” reason for failure. So why is that? Because “failure” always means that someone’s expectations regarding your results were quite different from those you actually achieved. Of course the degree of failure always depends on the significance of the people who have those expectations, but the fact remains that “success” is not something that exists in a vacuum – it always involves judgement about the work that someone performed and judgement is only possible in relation to a certain set of expectations.

In the end, not managing expectations is and always will be the only reason for regarding work or its results as failure. Or, as J.D. Meier put it: “Managing the expectations as the stakes go up, becomes increasingly important in how your work is received, acknowledged, and rewarded.” – or to quote General George Patton: “Success is how high you bounce when you hit bottom.” (read more here)

So how can we manage expectations effectively? As always, the first thing to do is to acknowledge that there are expectations somewhere and invest time to understand them. The most efficient way to do that is very simple: Ask the right questions!

In our basic consulting seminar we have a section called “assignments & expectations”, which I already described partly in my blog post “How to Approach New Assignments”. The second part of this section is basically about how to invest time for negotiating what success means to the important people around you. Some of the vital questions we suggest to ask are the following:

  1. What is your perspective on the current situation?
  2. What are your minimum requirements for a desirable outcome and what would success look like?
  3. What are your goals in this given context and what else is important to you?
  4. What should be my goals from your point of view and how would you proceed to achieve them?
  5. What kind of backing / support can I get from you?
  6. Which early wins should we aim for without sacrificing sustainability?
  7. How would you set priorities within the current context?
  8. How can we win other stakeholders to our way of thinking?
  9. How can we team the necessary mindset that enables change to other stakeholders?
  10. How can we keep other stakeholders focused on what is really important?

Of course there are many more questions you can ask, but for successfully managing expectations – and in a way avoiding outright failure – these should be the vital few.

The second key to successful expectations management is: Keep asking! Just having some initial answers to the questions above might be fine for a limited amount of time, but expectations inevitably shift and often change drastically over the course of a relatively short time frame. Therefore, establishing a routine for periodically reassuring that you’re still on the right track is equally important for performing well and achieving success.

The third recommendation we give is embodied in the two statements at the beginning of this post: Always reduce your commitment to the lowest common denominator and never promise anything you can’t keep. In addition, always restate your understanding of every agreement and ensure that everything you say has been understood in the same way by all stakeholders.

If you keep these principles in mind and take the necessary actions, you will probably still fail – but your degree and your rate of failure will be much lower than your rate of success. Even more importantly, however, will be the trust and the faith people will have in you and in your ability to produce successful outcomes. And that is something money can’t buy.

How to Approach New Assignments

Transitions are one of the few situations in every career where time is of the essence and therefore acting quickly and decisively is critical for success. But are new jobs the only situation in which the environment changes nearly instantly and in which you have to adapt to completely new goals and expectations? If your job has something to do with projects or you work as a consultant, the answer is probably “No”.

So instead of wasting time with the wrong things and trying to figure out what you should do in which order, why not use the ECM framework to provide you with a simple step-by-step process  that can help you to master your new assignment successfully.

  1. Invest Time to Collect, Process and Organize All Available Information
  2. Analyze the Situation and Take a Look at the Big Picture
  3. Search for Root Causes and Define the Minimum Requirements for Success
  4. Ensure Your Visibility without Sacrificing Sustainability
  5. Outline the Strategic Direction and Set Goals based on a Realistic Scope and Timeline
  6. Get Feedback Early, Negotiate Support and Build Strong Coalitions
  7. Get Your Reporting in Order and Make Sure, You Know Always Where You Are
  8. Manage the Expectations of Others and Build Productive Relationships
  9. Focus on the Real Priorities and Balance Conflicting Interests
  10. Align Structures, Processes and Systems with Your Strategy
  11. Get the Right People with the Right Skills into the Right Jobs
  12. Execute Your Plan, Control Your Results and Adapt to Change Quickly
  13. Make Sure to Receive and Incorporate Feedback

Interested in learning more about the ECM framework? Stay tuned…

Management by Objectives in the 21st Century

When Peter Drucker introduced the concept of Management by Objectives more than half a century ago, he probably didn’t imagine that it would remain one of the most problematic responsibilities for managers even 50 years after the initial release of “The Practice of Management”. The most common root causes for this situation is probably the missing link between the goals of the organization on one hand and the actions of the professional knowledge worker on the other – despite that he is the one who has to deliver the right results. One possible approach to create (or restore) this link is to acknowledge that goals – especially yearly performance goals – are often being defined based on a plain and simple job description. While there is nothing wrong with “plain and simple” per se, a “job” itself and most of the directly related aspects like roles (“Sales Manager”) and responsibilities (“Lead Generation”) are fairly static and abstract. And so the process of setting performance goals – more often than not done by someone who lacks the time, energy and appreciation for its importance – ends up being neither very action-oriented nor results-focused.

In strong contrast, this article focuses on the characteristics of a seemingly similar but actually quite different concept called “assignment”, which is much more directed towards performance and achievements. Despite the fact that both terms are often incorrectly being used interchangeably, assignments integrate context and situation, embody concrete actions and outcomes, and demand a greater focus on accountability, authority, competencies and resources. If combined with the clear understanding that goals, objectives and targets are three different and complementary concepts rather than just three terms for the same thing, your chances for creating an execution-oriented culture rise substantially.

It all begins by starting each individual assignment definition with a concrete discussion about the right results (goals, objectives, and targets) with every member of the team. While goals should be aligned with the companies vision and mission, and can therefore be wider and more visionary, objectives should be clear, realistic and specific. Last but not least, defined targets should than focus on the measurable aspects of objectives and be aligned closely with what the business unit is expected to deliver as part of the overall corporate strategy. After these three basic aspects have been defined, it is then necessary to discuss what is expected of the assignee (accountabilities and competencies) and what support he will receive (authorities and resources) to succesfully complete his assignment. In regard to accountabilities and authorities, it is essential to understand that they are two sides of the same coin – you cannot make someone responsible for something without granting him the right to make decisions about it. In addition, expecting certain competencies from employees also means to offer them the necessary resources to get the job done.

For this approach to be successful, effective managers should also avoid to make the assignments of employees either too big or too small. As it is inherently difficult to find exactly the right balance each and every time for each and every employee, it is usually better to aim a little higher and make the job a little bigger than to demand too little from someone. This technique is – if applied wisely – a very effective way to keep people on their toes. Again, every assignment must be achievable and aligned with the current reality, otherwise it will at some point start to kill off motivation by overstressing and overburdening the assignee. After an agreement has been reached and the assignment has been put in writing, it is now time to discuss a basic action plan and a number of pragmatic controlling procedures (which will be covered in another article).

However well defined the final assignment and its related action plan might be, there is one thing for sure: Nothing is going to work as planned. That doesn’t mean that plans and predictions are worthless – they are merely one of the byproducts of something much more important: The process of planning itself. Therefore, effective managers should always integrate certain checkpoints – for example every 90 days – with every plan, which can then be used to adapt the assignments and their implementation plans to the current reality.

In the end, developing well-defined assignments for every member of a team is probably the most important skill of a manager in the 21st century – it is what managers are meant to do: Transforming resources into benefits by enabling other people to perform well in their work, achieve the right kind of results and contribute to the bigger picture.