jdd2014: game of throneware, or how not to get killed when a developer becomes a manager - jakub...
DESCRIPTION
You are a good developer, each year you learn more, each year you earn more. You become senior, you become architect, chief architect, chief principal officer architect, and, one day, you are at the top-payroll level, and there is no place to go. You are happy with what you do, but your wife/husband/bank keeps asking for more. What do you do? You go to middle management. What happens, when you become a manager? How do you organize teams, workspace? How do you help people? How do you deal with politics, communication? What has the position of your desk to do with the architecture of your systems? How do you make decisions?TRANSCRIPT
Game of Throneware
or how not to get killedwhen a developer becomes a manager
Jakub Nabrdalik
10+ years asBusiness Analyst
Software DeveloperTeam Lead
Program ManagerProduct OwnerScrum Master
Solution/Software ArchitectHead of Software Development
Chapter 2How a developer becomes a manager
Lesson 1: all man must die
Lesson 2: dead men cannot help their teams
Lesson 3
Why building a companyis different from building software
Chapter 3
there is an app…a book for that
Complexity
One thing I learned, painfully, is that no matter what you plan for the system, it is not going to happen. The world doesn’t work that way. The system you live in doesn’t care about your plans. You may think that A leads to B, and in theory, you might even be right. But theory rarely works in practice, and predictability has a devious sister named complexity.[Jurgen Appelo; Management 3.0]
No silver bullet: what can you do?
experiment
observe, listen
adapt
It’s not a tutorial, it’s a case study
Chapter 4Politics and communication
Lesson 1: for direct people
Before you talk, think about what goal you want to achieve, and whether what you’ll say is bringing you closer to the goal.
Compare
This idea is completely stupid, and impossible to implement with our teams!
Compare
This idea is completely stupid, and impossible to implement with our teams!
It’s an interesting idea, but I have doubts whether it suits our situation. Can you create a proof of concept for that?
Lesson 2: for simple people
Everyone has an agenda
Learn what the other party wants, and use it (align their goal with yours)
Example: Linux
Example: consulting
Lesson 3: body language
Lesson 3: body language
The less direct the channel of communication, the more likely you are, to be misunderstood
face2face > video > chat > email
Organize things
Chapter 5
system architecture vision document
how people are split into teams
where your desk is located
What is more important?
System architecture vision document
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"M. Conway
How people are split into teams
"Your team structure will override any architecture you have" Jeffrey Sologov
Conclusion:small (scrum) teams = microservices
Where your desk is located
Where your desk is locatedFap setup
Where your desk is locatedFap setup
advantages:porn time!privacy!ogame!
disadvantages:teams? R U kidding?
Teams
Designated group of people, is not a team
Team is a group of people that works together, on a common goal
Where your desk is locatedIsle setup
Where your desk is locatedIsle setup
advantages:some privacysome cooperationsome porn
disadvantages:I need to get up? F you!
Where your desk is locatedTeam setup
Where your desk is locatedTeam setup
advantages:turn around/lean to helpself controlling systemself motivating cultureopen
disadvantages:no porn
system architecture vision document
how people are split into teams
where your desk is located
It has to go together!
Decision making
Chapter 6
Here are the tasks. Now do it!
Explaining WTF to your people is never on the picture!
Thus:decisions which (from other’s perspective) make no sensedecisions which (from other’s perspective) are bad for people and business
Engineers are built to solve problems
Throw a problem at themDescribe the constraintsLet them find a solution
but have your solution ready in case they won’t
Engineers accept a smart leader
Engineers accept a fair leader
How to be smart & fair?
How to be smart & fair?
Easy: just don’t be unfair & stupid!
How not to be unfair and stupid
trusttransparencyfairnesscooperation
Fairness
make the reasoning publicinclude all the partieslisten to everyone who has something to say
Fairness
Even if people do not agree, they will understand WHY a decision was made
Engineers accept REASONABLE decisions, even when they do not agree
Cooperation
Responsibility always comes with power
Empower people, and let them decide
Self organized teams
Self organized teams
What about a Team Leader?- watches for interpersonal problems- breaks impasse- veto right
Plan minimum (your expectations)- retrospectives (join, publish)- standups
Who said you have to have just one model?
Hiring - delegation/democracyReview - democracyTech problem - meritocracyOperating system - anarchyNew office design - feudalism
Decision making model
The sad truth
Chapter 9
meetings, end of flow
Having goals helps you get through
My goals:- make our development scalable- make 4finance the best place to develop- hire the best people- create culture of learning and improvement
But I wanna code too
Solution 1: Right Hand
Solution 2: Pair Management
Solution 3: Boy-scouts
Solution 4: MMA
No matter what you dobe an engineer
Problem with (free) time
Chapter 7
A dev always have something to do, even in an imaginary situation when his backlog is empty (learning, coding, games, porn)
What does a full-time scrum master do, when he has nothing to do?
Good people do, what they can
The people that do not code
Scrum masters optimize processes They do not stop on bottlenecks
Scrum masters need more meetingsEngineers hate meetingsEngineers do not work on meetingsProblem?
But: innovation happens only when you have time to innovate
You can have too much chocolateYou can have too much agile
Chapter 8
soft(s)killswork it out
Chapter 1
