Download as PDF, PPTX
Engineering Management - Challenges and misconceptions
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.
More Related Content
Similar to Engineering Management - Challenges and misconceptions
Engineering Management - Challenges and misconceptions
- 1. engineering management in anagile 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.
- 4. abstract An effective engineeringmanagement 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.
- 6.
- 7. what technologies shouldwe 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 theinfrastructure? budget compliance performance maintainability resources automation security robustness scalability availability disaster recovery control orchestration on-prem vs cloud … infrastructure as code
- 9. how to ensurequality? 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 wemanage code? versioning source code control branching models toolset merge policies feature toggles pipelines automation traceability metrics guidelines conventions …
- 11. how to promoteand ensure code quality static analysis code review pair programming reference architecture clean code guidelines design patterns naming conventions progress indicators … lifecycle
- 12. how much legacydo we have?
- 13. how do we keepan eye on everything
- 14. how do wekeep 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 shouldwe 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 tomake 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 thetechnical debt? “Debt is not to be paid... it is supposed to be managed” hummm…. not a good example…
- 18. what about thetechnical debt? negotiation prioritisation refactor needs issue heat maps slow downs analytics visibility …
- 19. and many more….fromplutora.com
- 20.
- 21.
- 22.
- 23. a completely differentchallenge…. 1x1s personal development conflict resolution feedback expectations management team composition hiring firing motivation noise filtering negotiation coaching training guidance … rewarding
- 24.
- 25.
- 26.
- 27. Spotify Everyone feels controlled Noconsensus 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.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. “hey, let’s doScrum, it will make our teams faster”
- 37. “hey, let’s doScrum, 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 doScrum, 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 likethe move into agile, but I need an ETA on every request that is done”
- 40. “i really likethe 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 theteam some perks to motivate them”
- 42. “let’s give theteam 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 somemetrics to track each team member’s performance”
- 44. “lets use somemetrics 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 toomove faster, let’s throw in more resources”
- 46. “we need toomove 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 toomove faster, let’s throw in more resources” effectiveness doesn’t scale linearly with more resources…
- 48. “let’s move onto micro services, looks like we will be able to move faster and with more quality”
- 49. “let’s move onto 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.
- 51. Systemic view “95 percentof 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 seethe 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 TedXtalk 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 featuretoggles dark launching test coverages test automation infrastructure as code auto-recovery … …or even better, get rid of the button and make it automatic.
- 57.
- 58. allow people tofail 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 toend responsibility avoid handovers+ empowerment
- 60. promote redundancy everyone shouldstop 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.
- 63.
- 64.
- 65.
- 66.
- 67. humble respectful trusting from “Team Geek”, BrianFitzpatrick and Ben Collins-Sussman
- 68. manager people technology processbusinessproduct
- 69.
- 70.
- 71.
- 72. thanks Antonio Arrais deCastro | linkedin.arraiscastro.com | Oct 2019