Some Thoughts on 10X Management Structures

• John Vandivier

Explain 10x thinking <a href="https://www.youtube.com/watch?v=QC_PGHkRvTw&feature=youtu.be&t=6m50s">per this video.

ideas:

  1. No pure manager role. Everyone has some technical skin in the game.
  2. Pure managers as executive proxies
    1. First, this seems a strict loss to technical efficiency, but maybe the exec is OK with that in exchange for sleep.
    2. Second, does your manager even do this? If not, why do they exist?
    3. Third, do they still need to be pure managers? or can they be technical managers and fill these shoes?
    4. Fourth, something actionable: Make managers owners. That is, give them some
  3. Pure managers as project SMEs
    1. I think some management roles exist because execs want a 'point person' on a project. Someone they can ping for updates, etc. There is absolutely no reason for this to be a pure management role.
  4. Managers as business SMEs
    1. Some managers exist because the technical staff doesn't know who to talk to with a non-technical question. For example, the technical staff works with the client to identify a new requirement and the client is willing to pay but this requires a contract modification, which is totally not a thing the developer knows how to do.
    2. With proper digital infrastructure this role can be automated. The developer could look up a Contracts Team contact on an internal directory, or send an email to a help desk.
    3. But, lacking digital infrastructure there may be a role for a dude, be that dude a guy or a girl, you know, a dude. A manager dude. But is he really a manager in this case? Like I don't think this is a project role so I wouldn't call it a project manager, and it doesn't seem a highly skilled role so I wouldn't dump management salary on it. It seems a horizonal-level, different skill specialty role. Like a business facilitator, or maybe a business intelligence role. Or maybe something else and idk the title.
An alternative would be to replace many pure managers with a hybrid developer-manager role, such as a tech lead, which actually codes some portion of the time. In small firms this is actually very common. It might take the form of a lead developer who also handles running scrum. As firms scale there is surely a need to aggregate reporting and other such concerns, but why is this 1) not automated and 2) coupled to a management function? You can have a business intelligence specialist who collects metrics from a scrum team without pretending to command that team's direction.

bad manager characteristics: see strategic micromanagement and the ITW article.

also:

  1. Insatiability: No matter how well you do you still aren't good enough. It may be a genuinely stupid manager who doesn't know how to identify talent, or it might be a strategically mean manager who thinks being an asshole or constantly threatening a firing is how you squeeze every once of productivity out of employees. But it isn't.
  2. Appreciation failure: The manager doesn't \"get the message\" about either good news or bad news:
    1. When a developer raises a concern, the manager glosses it over instead of acting to assist. \"OK thanks for the heads up, but I'm sure you can take care of it champ! You're the best!\"
    2. When a developer (or group) executes some task with unexpected quality, the developer is either non-satiated (from 1) or otherwise unimpressed, or simply ignorant of the difficulty involved. \"Oh you guys knocked that out in an hour instead of a few days? Hm I guess you estimated it wrong, better work on that next time.\"
    3. Often seen in non-technical managers. Technical managers don't usually have the same issue.
  3. Lack of leadership
    1. The leadership role is absolutely needed (whether or not you have a manager, you eventually get the leadership role from an exec or from the client)
    2. The manager is the leader by default. If he can't handle it he should facilitate someone else leading on some particular task.
    3. Leadership means providing priority among tasks for completion (should I work on A or B first?) and it also means identifying answers to business questions (should we go ahead and do A or do we need to check with the client, or should we just disregard the task?)
    4. Bad leaders are indecisive, or worse yet cowardly and afraid to decide. This ends up wasting time and frustrating other staff.