Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Paul Kimmel

Dr. Dobb's Bloggers

Are You a Macro or a Micro?

September 29, 2010

Macro-focused people are good at looking at the big picture, organizing tasks, planning, and keeping track of a lot of larger-picture details. Micro-focused people are good at managing a large number of details for one or two tasks. For example, a details person around a household might make sure all of the towels are folded and stacked a certain way. A macro focused person might be more interested in the price of ten thousand towels at the best price from a supplier.

Software can help people work at a micro level and a macro level. For example, I used Outlook and Word to negotiate and organize the macro aspects of a project. Then, I use something as basic as a word processor to decompose a macro set of tasks into micro tasks. Something like MS-Project can be used in the same way.

If someone only wants to focus on tasks then that person might be overwhelmed as a project manager but be a very good coder. If someone doesn't like the little details then that person may make a terrible tester. Identifying personality types is useful on projects. Promoting someone to manager because they are a good coder may be a terrible idea. Firing a manager that gets bogged down in details may be the wrong way to go too. Maybe that person is a better tester or programmer and should go back to doing that.

Here is one difficulty. Compensation levels often more highly compensate managers, so great technologists that want to make more money have to move into management even though they may be unsuited for such work.

Another difficulty is task switching. Some project roles like software architect demand times of activity around macro aspects and periods of focus on detailed technical problems. In this instance a person capable of switching between details and the big picture is needed, but such a person still needs time for both kinds of activities. Often big picture details require a lot of interaction with others, and technical challenges require a lot of intense alone-time.

The riskiest fallacy is that people are good at task switching. People in general are not great at multiple, parallel tasks. People are better at focusing on single tasks at a time and longer periods between switching tasks. Macros may be good at a higher frequency of task switching because they aren't lost in the bewildering array of details. Micro-focused people need intense periods of uninterrupted time. A good solution is know the roles people are playing and leave the micro people out of details, like frequent meetings and discussions, task switching. Assign such people high level tasks, ask them to break the task into smaller details and then leave them alone. Let your macro detail people attend meetings and then selectively figure out when to convey the new information to the detail people.

The way this can play out badly is as follows: detailed people like programmers in customer meetings cause these meetings to devolve into technical discussions about how when such meetings need to stay focused on what. Big picture people tend to talk about a lot of different tasks. These people interacting with micro detailed people too much cause detailed people to end up switching focus too much. What does this look like in practice? In practice keep the number of connection points between big picture people like customers and managers and detail people like testers and developers to a minimum. The big picture people request macro -level goals and the detail people return how that solution will be composed (or broken down into manageable bits). Users seldom need to know the manageable technical bits and individual technical people need a general idea of the big picture but not immersion.Keep interactions between big picture people like managers and customers and detail people like developers and testers to a minimum. Detailed people need periods of high intensity alone time, and big picture people need interaction without the interrupt of digressing into details.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.