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?

1. Game of Throneware
or how not to get killed
when a developer becomes a manager

2. Jakub Nabrdalik
10+ years as
Business Analyst
Software Developer
Team Lead
Program Manager
Product Owner
Scrum Master
Solution/Software Architect
Head of Software Development

3. Chapter 2
How a developer becomes a manager

6. Lesson 1: all man must die

7. Lesson 2: dead men cannot help their teams

8. Lesson 3

12. Chapter 3
Why building a company
is different from building software

13. there is an app…
a book for that

16. 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]

17. No silver bullet: what can you do?
experiment
observe, listen
adapt

18. It’s not a tutorial, it’s a case study

19. Chapter 4
Politics and communication

23. Lesson 1: for direct people

24. Before you talk, think about what goal you want
to achieve, and whether what you’ll say is
bringing you closer to the goal.

25. Compare
This idea is completely stupid, and impossible
to implement with our teams!

26. 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?

27. Lesson 2: for
simple people
Everyone has
an agenda
Learn what the other
party wants, and use
it (align their goal
with yours)

28. Example: Linux

29. Example: consulting

30. Lesson 3: body language

33. Lesson 3: body language
The less direct the channel of communication,
the more likely you are, to be misunderstood
face2face > video > chat > email

34. Chapter 5
Organize things

35. What is more important?
system architecture vision document
how people are split into teams
where your desk is located

36. 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

37. How people are split into teams
"Your team structure will override any
architecture you have"
Jeffrey Sologov
Conclusion:
small (scrum) teams = microservices

38. Where your desk is located

39. Where your desk is located
Fap setup

40. Where your desk is located
Fap setup
advantages:
porn time!
privacy!
ogame!
disadvantages:
teams? R U kidding?

41. Teams
Designated group of people, is not a team
Team is a group of people that works together,
on a common goal

42. Where your desk is located
Isle setup

43. Where your desk is located
Isle setup
advantages:
some privacy
some cooperation
some porn
disadvantages:
I need to get up? F you!

44. Where your desk is located
Team setup

45. Where your desk is located
Team setup
advantages:
turn around/lean to help
self controlling system
self motivating culture
open
disadvantages:
no porn

47. It has to go together!
system architecture vision document
how people are split into teams
where your desk is located

48. Chapter 6
Decision making

49. Here are the tasks. Now do it!

50. Explaining WTF to your people
is never on the picture!
Thus:
decisions which (from other’s perspective) make no sense
decisions which (from other’s perspective) are bad for
people and business

51. Engineers are built to
solve problems
Throw a problem at them
Describe the constraints
Let them find a solution
but have your solution ready in case they won’t

52. Engineers accept a smart leader

53. Engineers accept a fair leader

54. How to be smart & fair?

55. How to be smart & fair?
Easy: just don’t be unfair & stupid!

56. How not to be unfair and stupid
trust
transparency
fairness
cooperation

57. Fairness
make the reasoning public
include all the parties
listen to everyone who has something to say

58. 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

59. Cooperation
Responsibility always comes with power
Empower people, and let them decide
Self organized teams

60. Self organized teams
What about a Team Leader?
- watches for interpersonal problems
- breaks impasse
- veto right
Plan minimum (your expectations)
- retrospectives (join, publish)
- standups

61. Decision making model
Who said you have to have just one model?
Hiring - delegation/democracy
Review - democracy
Tech problem - meritocracy
Operating system - anarchy
New office design - feudalism

62. Chapter 9
The sad truth

63. meetings, end of flow

64. 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

65. But I wanna code too

66. Solution 1:
Right Hand

67. Solution 2: Pair Management

68. Solution 3: Boy-scouts

69. Solution 4: MMA

70. No matter what you do
be an engineer

71. Chapter 7
Problem with (free) time

72. 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?

73. Good people do, what they can

74. The people that do not code
Scrum masters optimize processes
They do not stop on bottlenecks
Scrum masters need more meetings
Engineers hate meetings
Engineers do not work on meetings
Problem?

75. But: innovation happens only
when you have time to innovate

76. Chapter 8
You can have too much chocolate
You can have too much agile

78. Chapter 1
soft(s)kills
work it out

86. Good luck
jakubn@gmail.com