ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
Developers and managers don't get along
Developers chafe
Managers chase
Developers resist
Managers reorg
Developers quit
Managers quit
... and projects, meanwhile, fail, fail, fail...
If developers and development managers want to achieve happiness, harmony, and efficacy (which are prerequisites to having successful IT projects), we have to understand each other
In 1992, a book describing the differing mental models of relationships, organized by gender, tried to help couples see how each was inadvertently creating problems by assuming that the other was thinking the same way they were.
Men are from Mars, Women are from Venus, became an instant classic.
In it, the author likens men and women as being from different planets (Mars and Venus), and claims that these "Martians" and "Venutians" have diametrically different communication styles, emotional needs, and personal values from each other.
Only by understanding these differences do we reach understanding.
Sound familiar to anybody?
These are gross stereotypes
(Though stereotypes generally have a lot of truth in them)
I wasn't thinking of anybody in particular when I wrote these slides
(That's my story and I'm sticking to it)
I am not trying to offend anybody
(More accurately, I'm trying to offend everybody equally)
I grew up "developer"; became "manager"
(My biases will shine through, I'm sure)
There are no heroes, and no villains, in this talk
Make the world more complicated and complex, of course!
Developers seek to solve problems
... which usually means writing software to provide automation
... that other people have
... because developers are experts in computers, not other things
... that haven't been solved before
... because if it's already been solved, it's automated already
... by telling computers what to do
... creating new code/scripts
... evaluating the results
... anticipating possible failure conditions
Software development is fundamentally an act of creation
... which requires inspiration and creativity
... focus and intensity
... like trying to put together a puzzle
... or trying to create a new puzzle
... or writing or painting or "innovating"
The act of creation is best done in "flow"
"Psychological Flow captures the positive mental state of being completely absorbed, focused, and involved in your activities at a certain point in time, as well as deriving enjoyment from being engaged in that activity."- https://positivepsychology.com/what-is-flow/
“My mind isn’t wandering. I am not thinking of something else. I am totally involved in what I am doing. My body feels good. I don’t seem to hear anything. The world seems to be cut off from me. I am less aware of myself and my problems.”- https://positivepsychology.com/what-is-flow/
“... being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you’re using your skills to the utmost.”- https://positivepsychology.com/what-is-flow/
Almost every developer craves this state
Almost every human craves this state, in fact
What do developers want?
clear goals and tasks
opportunities to slip into a Flow state
understanding where/how what they work on "fits in"
psychological safety with their team
growth, growth, growth
Autonomy
to perceive we have choices; to feel that what we are doing is of our own volition; that we are the source of our actions
Relatedness
need to care about and be cared about by others; to feel connected to others without concerns about ulterior motives; to feel that we are contributing to something greater than ourselves
Competence
to feel effective at meeting everyday challenges and opportunities; demonstrating skill over time; a sense of growth and flourishing
but notice the phraseology here
passive, being "acted upon"
not "doing" but "being done to"
what's doing the driving?
we are motivated to get what we don't have
if you are thirsty, you are driven to drink
if you are hungry, you are driven to eat
but what happens after we drink or eat?
we aren't interested until we are thirsty or hungry again
psychological needs are not 'drives'
People who experience ARC do not need 'drive'
they are thriving already
dysfunction exists because our needs for ARC are not being satisfied
... really, just ask any Dilbert cartoon
... honestly, most developers have no clue
set a vision, create goals, hold people accountable
clear the team away from obstacles (or vice versa)
nurture/grow relationships of the team to the rest of the organization
find, shield, and nurture talent
managers are all about human relationships
... which means talking with other humans
... or, in other words, meetings
Vision: Big picture of what you want to achieve.
Mission: General statement of how you will achieve the vision.
Strategy: Strategies are one or more ways to use the mission statement in order to achieve the vision statement. Although an organization will have just one vision statement and one mission statement, it may have several strategies.
People
Dependencies on external entities
software
processes
Budgetary constraints
How is your team perceived?
What other teams does your team need? Who needs you?
How are you improving the relatioships?
What new relationships are needed?
you don't want just "the best"
All-Star teams don't always turn in the best results
what talent do you have?
what weaknesses are there?
where is the next generation coming from?
how are they growing?
who is your successor?
when will you promote them out of your team?
how are they interacting with each other?
Many managers find it hard to motivate people
... because they're looking at it wrong
... so they seek "passionate" people
... because passion needs no motivation, right?!?
People are already motivated
Your job is to find out:
What is motivating them
What they're motivated to do
Then tie your vision to their motivation
The project was on schedule
They were using a leading-edge language
They were mentoring other developers in the company
They were signed up for an advanced training class
They were revising their process and stripping away inefficiencies to hit milestones
The developers were motivated!
Then the team lead met with the boss ...
The project was on schedule
so they advanced the deadline by three months
They were using a leading-edge language
... so management thought they could do more, faster
They were mentoring other developers in the company
... so management canceled the mentoring program to free up time
They were signed up for an advanced training class
... so management canceled the training class to free up time
They were revising their process
... so management ordered them to "follow the corporate standard" to free up time
The developers weren't so motivated anymore
... so everybody was out by 5
The project was on schedule
They were using a leading-edge language
They were mentoring other developers in the company
They were signed up for an advanced training class
They were revising their process and stripping away inefficiencies to hit milestones
The developers were motivated!
Then the project team meets with the boss (you)
Prior to this, the boss (you) met with the "skip"
The competition was coming out with a new release
This new release would steal a march on the company
This might put the team's existence in jeopardy
Moving up the schedule seemed the safest path
wrong way: what we saw before
no autonomy
no relatedness
no competence (or faith in)
wrong way: what we saw before
better way:
how do we give the team autonomy?
how do we give them relatedness?
how do we improve their competence?
Accept that you are different and likely to stay that way
Developers are a necessity
Managemers are a necessity
... and the system in which we work is likely to remain
Capitalism is not going anywhere
... despite the open-source ecosystem
Managers: Accept that you do different things
Developers aren't laborers; more like scientists or artists
Developers aren't performing the same tasks every day
Developers cannot just drop into Flow on demand
'Scientific Measurement' (management by metrics) is broken for creative tasks
Developers: Accept that you do different things
Managers have to report progress
Projects have to be evaluated for success/failure
Planning is required in any sane enterprise
Managers are constrained by issues beyond your team
Accept that there is far more to this
... than what I can cover in one talk
The Management Myth: Why the Experts Keep Getting it Wrong
Matthew Stewart; W.W.Norton & Company
Why Motivating People Doesn't Work
Susan Fowler; Berrett-Koehler Publishers, Inc
Rapid Development
Steve McConnell; Microsoft Press
HBR's 10 Must Reads on Managing People
The Inmates Are Running the Asylum
Alan Cooper
Managing Humans
Michael Lopp; APress
Drive
Daniel H. Pink; Riverhead Books