This document discusses challenges and misconceptions around engineering management in agile environments. It addresses common threats like unclear goals, lack of autonomy and alignment. Effective management requires focusing on the team and system rather than individuals. Automation, allowing failures, avoiding silos and killing unproductive activities can help. A manager should act as a servant leader, coach and influencer to promote the team, sharing knowledge and adding value. The journey of effective engineering management is never-ending.

1. engineering management
in an agile environment
Antonio Arrais de Castro | linkedin.arraiscastro.com
challenges, threats, and misconceptions
Full Stack Porto #8 | Oct 2019

2. about.me
CTO @
lecturer @
CTO @
CTO @
PMO Director @
CTO @
PHD
linkedin.arraiscastro.com

3. working.at
www.edirectinsure.com
www.frank.co.th

4. abstract
An effective engineering management strategy needs to be in
total alignment with the company company’s vision while
being driven by its culture.
An engineering manager will probably not be successful if he
lives inside the technical domain and refuses to extend his
focus outside of its boundaries.
He/she will have a significant impact on the team’s morale
and company culture.
This presentation focuses on common threats and key
challenges typically associated with engineering management
in multiple contexts.
It also addresses common misconceptions about how it should
be done in agile environments.
More than focusing specifically on the engineer management
role (which means different things for different companies),
this presentation focus on the broader concept of engineering
management.

5. engineering.managament

6. the fun part

7. what technologies should we adopt?
Web components Polymer
risk analysis
team know how
compatibility
performance
reusability
scalability
security
maintainability
stabilitybottlenecks resources
support
training hiring
decoupling level
architecture
…
learning curve

8. what about the infrastructure?
budget
compliance
performance
maintainability
resources
automation
security robustness
scalability
availability
disaster recovery
control
orchestration
on-prem vs cloud
…
infrastructure as code

9. how to ensure quality?
unit tests
integration testing
compatibility
regression testing
stress testing
quality assurance roles
quality metrics
progress signals
approach (tdd, bdd, hybrid, …)
…
test cases
acceptance criteria
functional vs. non functional
compliance testing
security testing

10. how should we manage code?
versioning
source code control
branching models
toolset
merge policies
feature toggles
pipelines
automation
traceability
metrics
guidelines
conventions
…

11. how to promote and ensure code quality
static analysis
code review
pair programming
reference architecture
clean code guidelines
design patterns
naming conventions
progress indicators
…
lifecycle

12. how much legacy do we have?

13. how do we
keep an eye
on
everything

14. how do we keep an eye on everything?
monitoring
logging
alerting
system analytics
application analytics
user tracking
business metrics
predictive/ai
…
security
pattern
aggregation
dashboards
integration

15. how often should we releasing?
culture
mission
product backlog management
uat
product lifecycle
mindset
compliance
feature toggles
decoupling
dependencies
automation
test coverage
autonomy
viable increments
risk tolerance
rule of thumb: release as soon as doable, ship first, learn fast, react fast

16. and how to make it inexpensive?
feature toggles
canary launching
dark launching
blue and green
continuous integration
continuous delivery
continuous deploy
virtualization
serveless computing
auto rollbacks
rule of thumb: releases should be a no brainer, not drama
DRONE
…
containers

17. what about the technical debt?
“Debt is not to be paid...
it is supposed to be managed”
hummm…. not a good example…

18. what about the technical debt?
negotiation
prioritisation
refactor needs
issue heat maps
slow downs
analytics
visibility
…

19. and many more….from plutora.com

20. but…

21. engineering
management
management of the
technical domain>

22. managing people

23. a completely different challenge….
1x1s
personal development
conflict resolution
feedback
expectations management
team composition
hiring
firing
motivation
noise filtering
negotiation
coaching
training
guidance
…
rewarding

24. typical challenges

25. clear
clear
goalscommunication

26. autonomy
empowermentalignment

27. Spotify
Everyone feels controlled
No consensus on direction
Empowered but independent
Misalignment on the goals
More autonomy, empowerment
Unified goals, clear direction
Everyone works for the same goal
Micro management
Low Alignment
Low Autonomy
High Alignment
Low Autonomy
High Alignment
High Autonomy
Low Alignment
High Autonomy
autonomy empowermentalignment

28. team
motivation

29. baby sittingwithout

30. move FAST

31. avoiding overload

32. take
shortcuts

33. avoiding hitting a wall

34. {more}
Innovation

35. misconceptions

36. “hey, let’s do Scrum, it will make our
teams faster”

37. “hey, let’s do Scrum, it will make our
teams faster”
A poorly designed agile process may turn your teams slower at the end!
The easiest part is to earn dev team’s buy in.
A scrum team will struggle in a waterfall minded organisation.
The biggest investment is to feed the proper agile mindset across the board.
Scrum is a framework + a mindset, not a methodology.

38. “hey, let’s do Scrum, it will make our
teams faster”
common challenges
Choose an adequate sprint size.
Start with 1 week if prios change too often.
Release frequently.
Automate releases.
Go with Kanban/Scrumban if all of the above
are undoable.
stable sprint backlog
Implement (and don’t skip) refinements.
Work closely with product and business.
Coach everyone.
Break the unbreakable.
Small is beautiful.
Negotiate.
manageable user stories
Be lean on planning.
Avoid waste.
Try to achieve minimum viable predictability.
Estimates may help see what fits or not.
Estimate effort, derive duration.
Uncertainty is there, you can’t run away.
predictability
Allow teams to celebrate a completed sprint.
Adopt a sustainable speed/velocity.
Don’t push team to over commit.
Don’t use carrot sticks to compensate for bad
planning.
Carry overs are hell, they kill commitment.
commitment

39. “i really like the move into agile, but I need
an ETA on every request that is done”

40. “i really like the move into agile, but I need
an ETA on every request that is done”
You cannot continuously focus on value
… while stamping each request with an ETA
Team’s mission is simple
Deliver the most value as soon as possible
not
Deliver stuff that makes some people happy because ETAs were respected.

41. “let’s give the team some perks to
motivate them”

42. “let’s give the team some perks to
motivate them”
Our brains are programmed to habituate quickly to circumstances.
We tend to tune out events that happen repeatedly, no mater how positive.
Sometimes, in order to continue enjoying something we love, we need to miss it.
Variety and random events are helpful.

43. “lets use some metrics to track each
team member’s performance”

44. “lets use some metrics to track each
team member’s performance”
Team should be the organic unit, not individuals.
Focus more on the stream of value than on status.
Coach everyone to replace “My part is done” with “The team has done”.
Use releases as the most efficient way to report progress.
Avoid vanity metrics like the plague.

45. “we need too move faster, let’s throw
in more resources”

46. “we need too move faster, let’s
throw in more resources”
FORMING
STORMING
NORMING
PERFORMING
team changes may move the team back to an early evolutionary stage

47. “we need too move faster, let’s
throw in more resources”
effectiveness doesn’t scale linearly with more resources…

48. “let’s move on to micro services, looks like
we will be able to move faster and with more
quality”

49. “let’s move on to micro services, looks like we will
be able to move faster and with more quality”
cohesive unit of code
components designed to work together
easier to monitor
easier to debug
scalability is challenging
tight coupling (logic level)
dependencies (work level)
maintenance is expensive
expensive releases
slow downs
agility may be compromised
increased parallelism
easier to release
scales quite well
decoupling
increased complexity
partitioned storage
increased latency (can be minimised)
services will fail, focus on fault tolerance
challenging cross service debugging
bye bye classical transactions (hello saga pattern)
cyclic dependencies
monolith microservices

50. focus on

51. Systemic view
“95 percent of the performance of
an organisation is the result of the
whole system, not the individual”
management 3.0, Jurgen Appello
1.0
Optimize work.
Individuals are cogs in
the machine.
Heavy hierarchy
Efficiency
2.0 3.0
Focus on the system,
which includes
individuals and
relationships.
Management is
everyone’s responsibility
System
Focus on the
individual, make him
happy.
Heavy hierarchy.
Individual

52. How classical managers
see the organisation
How the organisation
really is

53. Systemic view
management 3.0, Jurgen Appello
build for meaning
innovate management
accelerate learning
run experiments
nurture happiness
manage the system
7 silver
bullets
managing for happiness, Jurgen Appelo

54. Systemic view
https://www.youtube.com/watch?v=hvJ4KlVlqV8Fun TedX talk with Jurgen Appelo about the challenges of becoming a manager

55. culture
startup highly debated “recipe”
But you cannot fake company culture!

56. automation
inexpensive releases
incremental deliveries
feature toggles
dark launching
test coverages
test automation
infrastructure as code
auto-recovery
…
…or even better,
get rid of the button
and make it automatic.

57. automation
from Atlassian

58. allow people to fail
don’t fingerpoint
invest in:
lessons learned dissemination
automated rollbacks
monitoring and visibility
fail fast, learn quickly, and improve
fire drills
use “what can be improved”
… instead of “who caused this???”

59. avoid silos
end to end responsibility
avoid handovers+ empowerment

60. promote redundancy
everyone should stop making an effort to be indispensable…
… but instead make a continuous effort to become essential.
adding value
sharing knowledge
helping others
promoting the team

61. kill unproductive activities
from “Team Geek”,
Brian Fitzpatrick and Ben Collins-Sussman

62. effectiveness productivity
focus.on instead.of

63. be a

64. servant leader

65. influencer

66. coach

67. humble
respectful
trusting
from “Team Geek”,
Brian Fitzpatrick and Ben Collins-Sussman

68. manager
people technology process businessproduct

69. learn.more

70. engineering.zen is reachable

71. but a.never.ending.journey…

72. thanks
Antonio Arrais de Castro | linkedin.arraiscastro.com | Oct 2019