class: middle, center, splash # The **Principal** Dev ??? - Make some noize! - Welcome, I will teach you principles (portable across domain). You can figure out practices. - Split into teams of 4, know each other names, role and background. --- background-image:url(manif0.png) background-size: contain --- background-image:url(manif1.png) background-size: contain --- background-image:url(manifesto0.png) background-size: contain ??? - close as many JIRA issues as possible? - deliver new features? : ) --- background-image:url(manifesto1.png) background-size: contain ??? - never ask a barber if you need a haircut (bias.) - if the only tool you have is a hammer, then every problem look like a nail. --- class: center, middle ## Customers don't need software and features. *They need cost-effective solutions to their problems.* --- class: center, middle ![:ribbon Exercise, small] ## Why software is *not* always cost-effective? ??? - hiring. - motivation. - well-crafted software is expensive; crappy software even more so. - manual labour can be cheaper than automation. - software is always a liability. Sometimes an asset. - software should be kept up2date (e.g. Node updates etc.) - software may hinder business agility (software is an artefact that need to be changed). - softwate teams lose effeciecy as they scale (diseconomies of scale). Minimize output, and maximize outcome and impact. - more features => higher ToC (including 'invisible parts' like customer service, slower teams) - more features => worse UX => unhappier users - opportunity cost. - data compliance. - no-code solutions (github.com/kelseyhightower/nocode) --- class: img50, center ## Our highest priority is to .hide[find **cost-effective** solutions to customers' problems.] --- class: img50, center ## Our highest priority is to find **cost-effective** solutions to customers' problems. --- class: center, middle ### 💡 The process of finding the cost-effective solution from a list of alternatives is called *Cost-Benefit Analysis (CBA)*. #### speed · cost · benefit · risk --- class: center, middle ![:ribbon Exercise, small] ### Find a cost-effective solution to the following problems: ??? - preferably, without writing much code. --- class: center, middle ![:ribbon Exercise, small] ### (1/2) Backlog Item #JR-1234: #### Taxpayers are required to submit tax reports from February 1st to March 31st. Every year, during that period, our system becomes unresponsive, because taxpayers rush to submit documents as soon as they receive email reminders. Solution suggested by the chief architect: make the system auto-scalable by migrating to AWS. 🙈 --- class: center, middle ![:ribbon Exercise, small] ### (2/2) Backlog Item #JR-2345: #### As a business analyst, I want a UI for complex data querying, filtering, and reporting so that other business analysts and I can query any information from the database, analyze data, and build visual reports. See UX wireframes enclosed. 🙉 --- class: center, middle ### 💡 Don't do what the customer wants. Do what the customer needs. #### (cost-effectively) --- class: center, middle ### 💩 Shielding developers from dealing with the business leads to low trust, low motivation, mediocre software solutions (*software is the implementation of the business*), and turns on destructive reinforcing loop. --- class: center, middle ### ♻️ Less involvement → less understanding → less impact → less involvement. #### (if devs cannot find meaning in business, they'll find it in tech.) --- class: center, middle
--- background-image:url(manifesto_business.png) background-size: contain ??? - Like in a startup. --- #### 1. Job title "**.question[〰️〰️〰️〰️].answer[solution]** developer" better describes our job. --
-- #### 2. To find **.question[〰️〰️〰️〰️].answer[cost-effective]** solutions, you must *understand the biz and the context*. --
-- .group[ 🧠 Useful mental models: - Explore → Expand → Extract (3X, Kent Beck) - Explore → Exploit → Sustain → Retire (Lean Enterprise, Barry O'Reilly) - twitter.com/eduardsi/status/1602542896787644417 ] -- #### 3. Understanding of the business turns you into **.question[〰️〰️〰️〰️].answer[biz partner]** and gives you **.question[〰️〰️〰️〰️].answer[CBI]**. --
-- #### 4. To understand the business, you must be **.question[〰️〰️〰️〰️].answer[involved]** in the business. --
-- #### 5. A good product ~~owner~~ leader should **.question[〰️〰️〰️〰️].answer[connect]** biz and tech. --
--  ??? only 100 pages. Full of wisdom. Can be applied next day. --- class: center, middle ![:ribbon Exercise, small] ## How to turn software developers into solution developers / architects? ??? - Start with "why", and let the team figure out "how". - Impact Mapping - DDD - Refactoring UI - Make sure engineers actually use products they develop. - Grant everyone access to business data and analytics. - Don't hire "hackers". Hire problem solvers. - Make sure business + engineers sit next to each other (and hang out together). - *Use "we" vs. "they" when talking about business.* - *Leverage = Impact ÷ Effort (maximum impact, minimum effort)* - *Go to gemba.* --- class: center, middle
Your browser does not support the video tag.
### John Carmack @ Lex Fridman Podcast, 2022 --- class: white, bottom background-image:url(demand_supply.png) background-size: contain ??? - How orgs work: explain the black box. - When you become a leader, *your output is the output of your team(s);* the black box; - *Most engieners fall into the IC trap*: you become a leader because you're a good IC. :-) So it’s tempting to keep doing IC all day long. But there is also mentoring, recruiting, meetings, budgeting, strategic planning… And you only have 8H a day. So, from my experience, most engineering leaders are busy, overwhelmed, and unhappy. And you can't be a good leader if you're busy. The worst leaders are busy. - *Can you combine organizational and technical work and not be busy?* Yes! How? By focusing on High-Leverage Activities (HLAs). --- class: middle, shift-left ## High-Leverage Activities (HLAs) #### The activities with the highest return on your time investment. 💡 Leverage = Impact ÷ Effort  --- -- #### 🔴 Write code (better and faster than others). -- #### 🟠 Control quality. -- #### 🟢 Build a culture of technical excellence. ??? - culture is what happens when you're not in the room. -- #### 🚀 Hire someone to do that for you / with you. --- -- #### 🔴 Work hard. -- #### 🟠 Hire many hard-working people. -- #### 🟢 Remove impediments. -- #### 🚀 Empower the team to see/prioritize/remove its own impediments. ??? - Make blackbox work for you. --- -- #### - Your output is the output of your team(s). -- #### - You only have ~8h of productive work. Busy ≠ Productive. -- #### - Focus on HLAs (The Pareto principle). ??? - 20% of activities give 80% of result. -- #### - To notice HLAs, don't overwhelm yourself with LLAs. -- #### - LLAs (4D): Delete → Defer → Delegate → Do ??? delegate => outsource first => then do in-house -- #### - Make blackbox work for you. 🌴🍹 -- #### - Apply second-order and high-order thinking. -- class: small-table | Action (with obvious first-level consequence) | Second-order consequences | System-level consequences | |:----------|:-------------|------:| | I solve everyone's problems. | I get more problems thrown at me. | I make the system more reliant on me. | | I hire QA Engineers because Devs can't keep up with testing. | I let devs dump on QA. | I reduce quality and throughput. | ??? - Share: *https://twitter.com/eduardsi/status/1578342573726662658* --  --- ### How to measure IT performance? ??? your custom KPIs matter. -- #### 1. Lead time
-- The time it takes to solve a problem. -- The time a problem stays "in progress". -- Can be reduced with: - Cost-effective solutions - Good architecture - Full-cycle teams (autonomous, cross-functional, self-organizing) ??? - good architecture reduces cost of change. - *To Slack:* More on full-cycle teams: * https://twitter.com/eduardsi/status/1379069894130597896 * https://twitter.com/eduardsi/status/1496374655720263680 * https://twitter.com/eduardsi/status/1496013177171345413 --  ??? - autonomous = no dependencies - cross-functional = necessery skills to solve problems - self-organizing = decide how to solve problem cost-effectively, no baby sitting, micro-management, and control --- ### How to measure IT performance? #### 1. Lead time
-- #### 2. Defects
-- #### 3. DDP
-- #### 4. Reliability
-- - Business folks understand business risks. Engineers understand tech risks. Surfacing tech risks is *our* job. -- - Identify risks with risk storming ➜ prioritize ➜ mitigate ➜ test (continuously) ??? - data center is destroyed, database is down, integrations fail, etc. - That's why unfortunately many companies do Happy Path Programming. -- - SLI, SLO, SLA, TTD, TTR. ??? - Serious about Site reliability engineering (SRE)? It's good if you know about - service level indicators. - service level objectives. - service level agreement. --- ### How to measure IT performance? #### 1. Lead time
#### 2. Defects
#### 3. DDP
#### 4. Reliability
#### 5. ROI
-- - What can you offer that the market can't? ... and forget about the market rate 💰. -- Cost-effective solutions, cost reduction, innovation, leadership, mentoring, visibility, hiring... -- - Think like CEO Understand where the business goes and help it get there. Have a solid business case for tech decisions. ??? - The best way to become a founder or business partner is to start thinking and behaving like one. - Tweet: https://twitter.com/eduardsi/status/1648309675233013760 -- #### 6. Satisfaction
??? - *Protip*: before lunch I mentioned that understanding of the business and domain is crucial for engineers for many reasons – to write better code, to offer cost-effective solutions, to become a business partner, to have a huuuge competitive advantage on the job market. Some (unusual) advice for you that can make you a better business thinker: - Become an investor. You don’t have to invest much. You can start with 100$ and Interactive Brokers account. This way, you’ll understand more about finance, cash flows, business models, shareholders, etc. And as a side-effect, will learn investing and make your first steps towards financial independence. - Becoming a contractor. Most of the time, you don’t even have to leave your current job. You just have to switch from employee to a contractor, and start paying your own taxes, handling accounting, expenses, etc. “Company of One” is also a business. As a side-effect, you’ll understand more about business and make more $ via tax optimization/dividends. - Spend as much time with non-engineers as you spend with engineers. When working as engineer, I was regularly inviting business people (from marketing, finance, and other departments) for coffees/lunch. Not only I built good relationships with people across the org, but also learned about non-technical side of business and got tons of valuable insider information. --- class: center, middle, splash # **Little's Law** --- class: center, middle, white  ??? - you want serviceman to focus only on you car, right? - Sixt, you have 5 cars, all needs a service. 1 is ferrari, others are Opel. $$$? --- class: center, middle, white background-image:url(little.png) background-size: contain --- class: center, middle ![:ribbon Challenge] ### Team has 20 cards in progress and throughput is 4 cards/day. ### Lead time = `____` days ??? - the exact number is not as important as understanding the relationship. --- class: center, middle ## 💡 Focus as many people as possible on as few projects/stories/tasks as possible. ??? - one thing at a time is what you have to aim for. --- class: center, middle, bad ## Why care about Little's Law if we use Scrum? 🤔 --- class: center, middle, oki ## Don't delay value delivery until the end of Sprint. --- class: center, middle, oki ## Scrum recommends "Swarming". --- class: white background-image:url(burndown.png) background-size: contain --- class: white background-image:url(burndown1.png) background-size: contain ??? - almost no value delivered in half a month (*you either earn or learn*) - most of the time, team is behind the schedule. - high risk of not delivering sprint scope (+ not delivering *any value* in case of interruption) - stress and pressure on testers, because they got work late and in a large batch); large batches take longer to test. - stress and pressure on devs if bugs found late in the sprint, technical debt / overwork. --- class: white background-image:url(noswarm.drawio.svg) background-size: contain ??? - We have a team of 3 developers and one test engineer. - And backlog with problems in priority order. --- class: white background-image:url(noswarm1.drawio.svg) background-size: contain ??? - Because most developers *prefer* working alone, they pull 3 problems. Problem per engineer. - WiP is *12 points*. Lead Time is *8 days*. --- class: white background-image:url(noswarm2.drawio.svg) background-size: contain ??? - Developers *love* multitasking (especially when blocked). Some believe that multi-tasking leads to faster completion (which is not the case). - *Task switching incurs high mental and time costs because of CONTEXT load/unload.* - WiP is *14 points*. Lead Time is *9 days* (or more because task-switching "eats" time) --- class: white background-image:url(noswarm3.drawio.svg) background-size: contain --- class: white background-image:url(noswarm4.drawio.svg) background-size: contain --- class: white background-image:url(noswarm5.drawio.svg) background-size: contain --- class: white background-image:url(game_over.jpeg) background-size: contain ??? - *picture a world after 10, 50, 100 such sprints :-)* --- class: center, middle # Let's turn on Swarming... ??? High WiP is default mode (because of psychology) unless swarming is facilitated by a team lead or agile coach. --- class: white background-image:url(swarm.drawio.svg) background-size: contain ??? Same team – 3 developers, 1 test engineer. --- class: white background-image:url(swarm1.drawio.svg) background-size: contain ??? - A great tool for enabling swarming is *setting an explicit WiP limit*. - Now let's say we set WiP limit = 1, which forces team members to decide which problem should they work on *together* (even though working alone is more comfortable) --- class: white background-image:url(swarm2.drawio.svg) background-size: contain ??? - The team pulls a problem with the highest value, say, some software feature, and decides how to *self-organize* effectively to solve it sooner. - WiP is *1 item or 4 points*. Lead Time is *2.5 days* (vs *9 days*) --- class: white background-image:url(swarm3.drawio.svg) background-size: contain ??? - People start doing more pair programming, because they work on the same problem, not different problems! :-) --- class: white background-image:url(swarm4.drawio.svg) background-size: contain ??? - No batches. We quickly test and fix fix issues properly. --- class: white background-image:url(swarm5.drawio.svg) background-size: contain --- class: white background-image:url(swarm6.drawio.svg) background-size: contain --- class: white background-image:url(swarm8_a.drawio.svg) background-size: contain --- class: white background-image:url(swarm8_b.drawio.svg) background-size: contain --- class: white background-image:url(swarm9.drawio.svg) background-size: contain --- class: white background-image:url(swarm10.drawio.svg) background-size: contain --- class: white background-image:url(swarm11.drawio.svg) background-size: contain --- class: white background-image:url(swarm12.drawio.svg) background-size: contain --- class: white background-image:url(swarm13.drawio.svg) background-size: contain ??? - faster, but also safer, w/o stress. Now you can improve codebase or do self-development. Life is good. :-) --- class: white background-image:url(burndown2.png) background-size: contain ??? - Continuous delivery of value, and the higest value is delivered first. --- #### *💡 Focus as many people as possible on as few projects/stories/tasks as possible.* ??? remember how it's called in Scrum? Swarming :-) -- * Swarming has its limits. Too many people working on a single problem can eventually hurt throughput. -- #### 💡 *Stop starting. Start finishing*. -- * Explicit WiP limits shift focus from pulling new work to completing existing work. -- * Explicit WiP limits enable swarming and force people to collaborate more (also across the roles). -- * Total WiP < of people in the team. -- - Show people opportunities for Swarming until they learn to see opportunities themselves. -- #### *💡 Low WiP reduces lead time, risks, stress, and improves teamwork.* --- class: center, middle
Your browser does not support the video tag.
### — Burnt (2015) ??? - Kanban can be used to improve any process. - Noize :-) --- class: center, middle     --- class: center, middle, white background-image:url(little.png) background-size: contain --- class: center, middle ![:ribbon Challenge] ## Work in Progress (WiP) exercise time! --- class: last-emphasize-h4 ### There are four ways to increase **throughput**: -- #### 1. Hire more people (🚨 danger) -- * Law of Diminishing Returns (adding manpower beyond certain threshold → less efficient ops) -- * Brooks's Law (adding manpower to a late project make it even later) ??? - Project is late unlikely because you don't have enough people. Hire people to solve the root cause. - What a small team cannot handle a large one will fuckup even more : ) -- * As a rule, small teams do better than large ones. ... small teams are faster, more flexible, more aligned, more involved, more engaged, enjoy better relationships, better knowledge sharing, low turnover, low management overhead... And are cheaper. -- * Two-Pizza Teams 🍕🍕 -- * Solve big problems with small teams. Consider *descaling* your teams. ??? - Twitter has 7,5k employees and it's unprofitable. Imaging descaling twittes team, saving billions, and rewarding shareholders and employees. - Airbnb 6k employees, unprofitable and EXPENSIVE for customers (people look for workarounds). -- * Need more people? Continuously refactor the company into a network of small, independent, full-cycle teams. --  -- #### 2. High-performance teams -- * Aligned -- * Small -- * Diverse -- * Full-cycle -- * Stable (Tuckman's stages of group development)  ??? - Forming–Storming–Norming–Performing -- * Psychologically safe -- * Moderately cognitively loaded (not switching between 10 products, domains, stacks) -- * Motivated -- * Skilled -- #### 3. Technical excellence -- - Pick your seniors/leaders carefully (people learn by imitation aka "social learning"). -- - Make sure your seniors/leaders promote *the right attitude, behaviors, and engineering practices*. -- - Make mentoring a prerequisite for promotion (you are only as good as your team). --       -- #### 4. Eliminate wastes --- ## Wastes of Software Development -- ###
Partially done work ??? - WIP :) -- ###
Overproduction ??? - code for the future :-) -- ###
Waiting / Handoffs ??? - long-running tests -- ###
Rework ??? - rebuilding UI because we didn't show intermediary results to our customers -- ###
Non-value added activities ??? - fixing marge conflicts --- class: center, middle ![:ribbon Challenge] ## Wastes exercise time! --- class: center, middle ## **Throughput and technical debt** ### (Bonus part) --- class: center, middle ### 💡 There is a strong correlation between the quality of the codebase and **throughput**. ??? - the shittier the code is, the less productive the team is. High quality = high throughput. --- class: center, middle ### The responsibility of the delivery team is to maintain steady throughput (velocity) over time. ??? - "implicit requirement", and because nobody is asking (and harder than confrontation) -> usually neglected. --- class: white background-image:url(threat000.png) background-size: contain --- class: white background-image:url(threat00.png) background-size: contain ??? - "invisible threat": small cuts, almost no throughput difference. in 2 years: oh shit! I see the difference. - and delivery team is slow and becomes a bottleneck to make world a better place :-) --- class: white background-image:url(threat0.png) background-size: contain --- class: white background-image:url(threat_laws.png) background-size: contain ??? - Can someone explain why throughput drops faster (exponentially) than it increases? ### Reinforcing loops: - Broken window theory - Lehman: as a system evolves, its complexity increases unless work is done to maintain or reduce it. (as we add functionality); - Brooks: adding people to late project make it later. - Gresham: (bad components drive out good components) --- class: white background-image:url(threat1.png) background-size: contain ??? - The rule that makes throughput gradually improve? - The (Boy)Scout Rule. --- class: white background-image:url(threat_loops.png) background-size: contain ??? - The rule that makes throughput gradually improve? - The (Boy)Scout Rule. --- class: white background-image:url(threat2.png) background-size: contain ??? - That's the currency of TD? We borrow throughput and pay with throughput. - unlike financial debt which is fixed, we pay compound interest. --- class: center, middle ### The currency of technical debt is throughput. We borrow throughput and pay with throughput (+ compound interest). --- class: whitebg background-image:url(compound.jpg) background-size: contain --- class: center, middle # Is technical debt a bad thing? 😱 ??? - raise your hand who thinks technical debt is a bad thing? - who thinks it's a good thing? - is taking a loan (credit) a bad thing? - it depends how you use and manage the debt. --- class: center, middle ### Technical debt is a **tool** for short-term gain. Causes addiction and must be carefully managed. ??? - unexpecteed problem, a black swan event --- class: bad *Manager*: When will the user authentication via Facebook be done? -- *Dev*: Mmmm, I hope tomorrow, at the end of the day. -- *Manager*: We need it today. Can’t you find a “creative” way to do it? -- ![:arrow Bad planning (fixed due date tasks first), right: 5px; top: -10px] -- *Dev*: Let me think… -- *Manager*: We have 25 clients that really need this today. Else they will probably not sign the contract. -- *Dev*: But the… -- *Manager*: Look, it’s important that you understand the business value of it. Isn’t it just a copy of Twitter authentication? Just make a copy, and we’ll “fix it” later. -- *Dev*: Ok. --- class: oki *Manager*: When will the user authentication via Facebook be done? *Dev*: Mmmm, I hope tomorrow, at the end of the day. *Manager*: We need it today. Can’t you find a “creative” way to do it? -- *Dev*: We can cut some corners and ship today while still delivering the remaining Sprint scope. Our velocity for the next Sprint will decline by 5 points because we'll need to pay the technical debt. -- *Manager*: Why? -- *Dev*: Suppose we don't pay the technical debt now. *In that case, the team's productivity will decline, velocity will disproportionally crash due to the compound effect, we'll lose our ability to plan, deliver on time, retain and hire programmers, and the culture of mediocrity will spread like cancer. However, it will save us 5 story points. Is that what you want?* -- *Manager*: That makes sense. Let's pay debt next Sprint. -- ##### 💡 Everyone should feel the consequences of borrowing. Free borrowing causes addiction. -- ##### 💡 Explain engineering decisions in a way that resonates with your audience. --- class: center, middle ### 🍿 Prioritizing Technical Debt as if Time and Money Matters #### **dev.tube/video/b9I3aOnXepA** --- class: white class: center, middle, img70  #### **twitter.com/eduardsi/status/1453283426036068368** --- class: last-emphasize-h4 ### 📉 4 causes of technical debt: -- #### 1. Knowledge/skills problem 🟡 -- - "What is cohesion?" - "TDD slows me down." -- - Solution: strong technical leadership and mentoring. -- #### 2. Attitude problem 🔴 -- - "I don't have time for quality." - "I am rugged senior dev. Tests are for juniors." -- - Solution: difficult conversations, escalation, shock therapy (hiring/firing). -- #### 3. Borrowing 🟢 -- - "We must ship now and pay the tech debt next sprint." -- #### 4. Learning 🟢 ??? Product development is a continuous discovery and learning process. -- - "We found a better way to do it." -- - Attract, develop, and retain tech and domain knowledge. -- - For unfamiliar domains use Google or 📚 Analysis Patterns: Reusable Object Models. -- - KISS, YAGNI, validate before building... --- class: center, middle ### 🍿 The Economics of Software Design #### **dev.tube/video/TQ9rng6YFeY** ??? We want the same thing, we just speak different language. --- class: center, middle # Q&A ??? - now you know about dev processes much more than most developers on the market. Tomorrow we'll do a recap and switch to a new topic - mentoring. --- class: center, middle # Mentoring ??? what is mentoring? --- #### **Deep understanding** -- 📚 The Guilt Pile -- △ The Learning Pyramid --- class: whitebg background-image:url(pyramid.png) background-size: 70% ??? - Reading and other forms of consumption are the weakest forms of learning. - Teaching is the most powerful form. Why more powerful than doing? - Consumption won't get you far, if you want to be expert at something. I know many devs who have read all good tech books, *know everything, but they don't understand anything.* --- class: center, middle ### To become an expert in your field... ---  -- 💡 *If you can't explain it, you don't understand it.* ??? to fully understand means doing much more than consuming or practicing. -- 💡 *Mentoring is the fast(-er) track to mastery.* ??? For engineers reluctant to teach, share, or work together – you're missing a huge opportunity. For those already mentoring – you're on the right track. Remember that when one is teaching, two are learning. -- 💡 Don’t feel guilty about the pile. *Consumption is LLA.* -- 💡 Allocate your (limited) learning time according to the pyramid. *Do more. Teach more. Consume less.* --- #### **Deep understanding** #### **Bus factor** ??? - bus factor, inverse bus factor - story that gave me bad publicity -- - The more influential your role is, the more you have to think about *succession planning*. -- 💡 Succession planning is a process and strategy for passing on leadership roles. It is used to identify and develop new, potential leaders who can move into leadership roles when they become vacant. -- * Leaders grow leaders. --- class: white, center, middle, img60  #### **twitter.com/eduardsi/status/1175405806059171840** ??? - test for your team ??? *To slack:* By the way, I ran into big trouble with finding consulting/interim CTO gigs, so I had to move to London, where more opportunities exist and some wouldn't involve reference checks. But it didn't help much, because when you're telling about your success story as CTO, they call your ex-employer for proof : ) It took me 3+ years to fix and boost the reputation as not only "engineering-friendly" but also a "business-friendly" person. So, *do what's good for business, make yourself replaceable and ensure business continuity.* --- #### **Deep understanding** #### **Bus factor** #### **High-performance teams** -- *1. Level Up 📈* --- class: white background-image:url(teamperf1.drawio.svg) background-size: contain --- class: white background-image:url(teamperf3.drawio.svg) background-size: contain ??? - Teamwork = we work together, and we help each other solve problems faster, better, with less rework. - We don't need more typing. We need more thinking (what to type and what no to type). --- class: white background-image:url(teamperf6.drawio.svg) background-size: contain --- class: white background-image:url(teamperf8.drawio.svg) background-size: contain --- class: white background-image:url(teamperf9.drawio.svg) background-size: contain --- class: white background-image:url(teamperf10.drawio.svg) background-size: contain --- #### **Deep understanding** #### **Bus factor** #### **High-performance teams** *1. Level Up 📈* -- *2. Level Sideways* -- 💡 *Theory of Constraints (ToC)* --  -- - *Optimize the bottleneck*. Optimizing non-bottleneck is LLA. -- - A bottleneck is any resource whose capacity is equal to or less than the demand placed upon it. A non-bottleneck is any resource whose capacity is greater than the demand placed on it. -- - Devs *waiting* for testing to finish, devs *waiting* for backend API, testers *waiting* for the Test API, etc. -- - Develop skills with capacity below the demand, even if they differ from your core expertise. -- - Insource missing competencies (architecture, process optimization, testing, etc.) -- *3. Hire T-shaped engineers (mentorable, non-religious about tech, open to pair programming)* ??? *To Slack:* Surprising to many, teams of T-shaped professionals generally do better than teams of narrow specialists (“I only do backend,” “I only do front-end,” “I do testing,” etc.). If you measure individual performance, then you’re unlikely to come to that conclusion because you’re measuring the wrong thing. However, once you shift focus from individuals to the black-box (optimizing the whole), the situation becomes clearer. Essentially, we want every team member to be able to solve a problem or complete a vertical slice of functionality independently. Or perhaps 90% of problems. And let specialists handle the rest. The advantages of T-shaped black boxes are: - Lead time: fewer hand-offs → shorter feedback cycle. - Adaptation: makes the team adaptable to the fluctuating demands imposed on the black box. Sometimes you need more FE, sometimes more BE, sometimes DevOps, etc. - Demand: ensures that anyone, not only specialists, can handle sudden demand spikes, unplanned work, code reviews, mentoring, troubleshooting, unexpected sick leaves, etc. This reduces waiting and bottlenecks. - Descaling: eliminates inflation inherent to specialist teams, where every specialization requires a minimum of two specialists for concurrency and failover. And you already know that small teams do better. - Planning: simplifies planning and work organizations, as biz/stakeholders/PO don’t have to consider the specialist capacity when planning/splitting work. Problem in → solution out. - Experts: frees up (expensive) specialists’ time and energy for tasks that require deep expertise, while other teammates can handle more trivial problems. - Collaboration: more opportunities and interest for collaboration, knowledge-sharing, pair programming, and reducing WiP. - Empathy: more empathy and understanding within the team. - Prototyping: more opportunities for entrepreneurship, business incubation, and R&D. It’s hard to prototype/ship value (quickly) if you’re not full-stack. A valid concern you might have is that technology stacks have become increasingly complex and evolve rapidly, often necessitating a dedicated individual to keep up. It's because "Over Engineer" is our second name. For instance, Htmx could be a better fit than React. A majestic monolith in most cases is more suitable than microservices. Kamal or Nomad over Kubernetes. The list goes on. Tech decisions shape our team composition. Team composition shapes our tech decisions. For inspiration: :popcorn: The World Needs Full-Stack Craftspeople: https://dev.tube/video/ipKw9hB2_bM :popcorn: Rails Conf 2023 Opening Keynote: https://dev.tube/video/iqXjGiQ_D-A :popcorn: From React to Htmx in Real-World SaaS Product: https://dev.tube/video/3GObi93tjZI --- #### **Deep understanding** #### **Bus factor** #### **High-performance teams** #### **Retention** -- - Retention is more important than hiring. ??? - Cost of losing a dev: domain knowledge gets lost, team spirit decreases, hiring, and onboarding, team re-building. --  -- - Autonomy.  -- - Mastery.  -- - Purpose.  --- #### **Deep understanding** #### **Bus factor** #### **High-performance teams** #### **Retention** #### **Recruiting** ??? - Recruiting is a modern cost center. How can we make great people eager to work with us? --- class: last-emphasize-h4, others-fade #### Improve quality of inbound traffic. -- - Be visible (because everybody else is invisible.) -- - Write ads that *attract good candidates* (attitude over skills, "Impostors") and *repel bad candidates* (skilled but lacking attitude, "Dunning Krugers") --  ??? - 70% of professionals are impostors. The percentage is higher among women. - The way most companies write ads repel way good candidates, and attracts bad candidates, quality of incoming traffic is very low. -- - Avoid hard requirements such as "3+ years of..." -- - Avoid "strong understanding of...", "deep knowledge of...", etc. -- - Describe environment, technology, and what the person will be doing. -- - Encourage people unfamiliar with some of your tech stack to apply. -- - Show your job ads to as many colleagues as possible. ??? *Share in Slack:* https://twitter.com/eduardsi/status/1502554143285649413 -- #### Beat expectations. -- - People should always walk out of an interview smarter, happier, energized (even if you didn't make a hire) -- - People talk to each other. Good for you and your employer. -- - Always start with a presentation (tell what you suck at!). -- - Replace ~~interviews~~ with conversations. -- - Be like ~~judge~~ mentor (see a knowledge gap? teach!). -- - Inspire with books. -- background-image:url(pp.jpg) background-size: 100% auto #### Let candidates code in their comfortable environment. ??? - question: at the interview, tells you: solve this simple code puzzle! code this! and you kinda struggling -- background-image: background-size: contain * The Hawthorne Effect.  -- * Homework is the most inclusive way to assess tech skills (and attitude). ??? - you can also give them choice. From my experience, 2 out of 100 programmers choose pairing. -- * Small, but useful (github.com/sizovs/awesome-homework-for-java-devs) -- - You owe the candidate a code review (good parts, bad parts, suggestions, books...) -- - Involve your teammates in code review (HLA). -- - People refusing to take homework is critical feedback. -- #### Bring a co-pilot. -- * More hiring capacity. -- * Feedback on how well the pilot did the job. -- * Just you and co-pilot (otherwise expensive, intimidating, candidates don't open up). -- ![:arrow optional (prevents cheating), top: 170px; right: -240px] #### Invitation ➜ Presentation ➜ Conversation ➜ Homework ➜ Review ➜ Discussion ➜ 🏁 --- class: smaller-p #### **Deep understanding** #### **Bus factor** #### **High-performance teams** #### **Retention** #### **Recruiting** #### **Reciprocity** --  ??? Six forces of influence. -- 1. Authority ??? - Your success story - Your position in a social hierarchy/community/company (that's why I wanted to become manager - to influence things) -- 2. Consistency ??? - *People are wired to act on what they say*. You should do what you say, otherwise you lose trust. And because doing things always requires time and involves risk. So people try to avoid commitment if possible :-) Spring planning: We have a problem. We need to work on that. Everybody is nodding and nothing is done. So, if you want people do something, you need to address specific people (not a group) and ask for explicit comittment - "Will you do this?", "Can I count on you?". And then, that will make them think hard if something is double, and once they do, the invisible hand will push them to do what they promised. -- 3. Liking ??? - the best way to hire a person (or to get a job) is to be liked :-) Show interest, curiosity, respect, make others feel good. Not outsmart. *By the way, if you don't care, people will notice it. Don’t try to be likable (because that will make you dislike you). Be likable person.* -- 4. Scarcity ??? - bitcoin :-) or "limited edition" products. - never marking myself "open to work", – works short-term :-) - Scarsity: professionalm/craftsmanship; domain knowledge; community; management skills; -- 5. Social Proof ??? - GitHub stars - Reference checks - Recommendations (principal dev) -- 7. Reciprocity --- class: center, middle ### In social psychology, reciprocity is a social norm of responding to a positive action with another positive action, rewarding kind actions. .hide[**As a social construct, reciprocity means that in response to friendly actions, people are frequently much nicer and much more cooperative than predicted by the self-interest model.**] --- class: center, middle ### In social psychology, reciprocity is a social norm of responding to a positive action with another positive action, rewarding kind actions. **As a social construct, reciprocity means that in response to friendly actions, people are frequently much nicer and much more cooperative than predicted by the self-interest model.** ??? - When you focus on yourself, why others should vote for you? or promote you? :-) - You succeed faster when you help others to succeed. Why? They benefit from it. People follow you. They support you. They protect you where things turned not in your favour. They recommend you to others. It's like having your own fan club. - And because in software world people grow so fast, change companies and even countries, that "junior" soon becomes your biggest and powerful promoter. --- class: last-emphasize, center, middle # 🧰 **Mentor's Toolbox** #### 5 primary tools --- #### (1/5) **Encourage** -- - Help people fight self-doubts. ??? - Everybody has some self-doubt; We are all have Imposter Syndrome. - Growth of most people is limited by internal conflicts or fears. Not lack of tech skills. Eliminate the conflict and they fly. -- - The #1 reason people leave jobs is lack of appreciation. -- 🔴 Thanks. -- 🟡 Thank you! -- 🟢 Thank you, John! -- 🚀 Thank you, John, for shipping X on time and with great quality. Keep rocking! -- - Support enthusiasm. --- class: center, middle background-image:url(peter.png) background-size: contain # **Let's rewrite everything in Kotlin.** --- background-image:url(consultants.png) background-size: contain class: center, middle # **Are you crazy or what?** --- class: center, middle ### 💡 Behind every request hides an unsatisfied need. #### Even if you're unable to fulfill the request, you can support or satisfy the underlying need. --- class: center, middle, video
Your browser does not support the video tag.
--- #### (1/5) **Encourage** #### (2/5) **Challenge** -- - Delegate technical and non-technical work. -- - Delegate tasks that maximize learning (trade-off with speed). ??? To twitter: https://twitter.com/eduardsi/status/1590381770910093312 -- - Delegate the most interesting work. -- - Coaching. --- class: center, middle background-image:url(peter.png) background-size: contain # **How can I make this code cleaner?** --- class: center, middle ## What options do you see? ### \#coaching --- class: center, middle background-image:url(peter.png) background-size: contain # **Where are the passwords located?** --- class: center, middle ## Let me challenge you – where have you looked? ### \#coaching --- class: center, middle background-image:url(peter.png) background-size: contain # **John writes crappy code. Life sucks.** --- class: center, middle ## What are you going to do about it? ### \#coaching --- #### (1/5) **Encourage** #### (2/5) **Challenge** #### (3/5) **Share** -- - Knowledge. 🧠 ??? - Brownbags -- - Energy. ⚡ -- - Optimism. 😁 --- #### (1/5) **Encourage** #### (2/5) **Challenge** #### (3/5) **Share** #### (4/5) **Set rules** -- - *Less control, more systems*. -- - WiP limits. -- - YBIYRI. -- - CI with daily push into the trunk. ??? - no isolation, forces to TDD, small chunks = easier code review -- - No junk in the trunk. -- - QA should find nothing. -- - Every time new pair. -- - Definition of Done. ??? - Passes tests. - Deployed to prod under feature toggle. - Has documentation --- #### (1/5) **Encourage** #### (2/5) **Challenge** #### (3/5) **Share** #### (4/5) **Set rules** #### (5/5) **Do together** ??? - Best way to learn, build great teams, and accelerate delivery (if you believe software dev is problem solving, not typing business) -- - Pair < Anything >. ??? - interviewing - leadership - conference speaking -- - Pair Programming. 👩💻👨💻 --- class: center, middle ![:ribbon Exercise, small] ## The hidden benefits of *pair programming*. ??? As promised, the “hidden” benefits of Pair Programming: * product development is thinking and problem solving business, not typing business. Two brains solve problems better and quicker than one. * tech, business, and problem knowledge transfer (reduces bus factor / knowledge silos) * builds relationships (leads to “Jelled” teams in Peopleware terminology) * building common values / understanding / language * reduces ego * reduces WiP * improves communication / explanation skills * amplifies learning for both juniors and seniors (tricks, shmicks...) - MASTERY! * rubber duck built in * better / safer onboarding :-) * better end solution and design * fewer defects, caught early * fewer assumptions * more focus, fewer distractions (Facebook, YouTube etc.) * people come more prepared * PP is an implementation of leadership by example and the best way to teach something * resolves disagreements, forces to discuss, understand, and agree in order to proceed. * protects against Sunk Cost Fallacy. * more fun cutting through boring / uninteresting tasks *together* * eliminates PRs (async code reviews) * eliminates interruptions caused by synchronous code reviews * eliminates rework that happens after every good code review * deeper / more thorough feedback (comparing to code review, when reviewer usually has less context and information about the problem) *To Slack:* And this: https://twitter.com/eduardsi/status/1173247001355522048 Also check out my write-up about code reviews. Everything written there applies to PP as well: https://sizovs.net/2020/07/19/the-code-review/ --- ### What skills my teammates need the most? 🤔 ??? sometimes we push things that people don't want. -- #### - Skills at the intersection of *personal career goals* and *team (blackbox) needs*. -- ### How to identify these skills? -- #### - *One-on-ones* (if you are a manager) ??? - open door policy doesn't work... – too late. One-on-one - to grow in this company or become the top engineer, I suggest... - is there anything that you don't like? - have a walk, have a coffee, do sports. Especially with those who don't support you. -- #### - *P2P review* (🍿 dev.tube/video/vQMYjpjpelg) -- #### - No goals? *Inspire career goals* yourself. --- class: center, middle ## "How do I convince my teammates to do X"? 🤔 --- class: center, middle # Nemawashi ### en.wikipedia.org/wiki/Nemawashi --- class: center, middle  --- class: white, center, middle, img70  #### **twitter.com/eduardsi/status/1481576094025543680** ??? - Many engineers struggle with getting support, even through they know what they're talking about. - The more people trust you, the fewer arguments you need to convince them. The less people trust you, the more arguments and effort you need. Trust is the currency of persuasion. --- class: last-emphasize-h4 ### Trust is the product of: -- ####
Your knowledge -- ####
Your consistency -- ####
Your authority ??? - position in social hierarchy, company, community. -- ####
Your confidence -- - Your market value. -- - Your ability to manage anxiety.  -- - Your mental and physical health. ??? Most people think that you have to add something to be healthy. 80% result comes from elimination of bad things or reducing consumption: - mass media. - gadgets. - negative people. - 0 alcohol policy. - solitude -- - Your environment. -- ####
Your charisma -- - Your energy. -- - Your body language (55%). ??? - Spoken words contribute to 7% of the message. -- - Your voice (38%). -- - Your words (7%). -- background-image:url(public_speak.jpg) - Can be mastered by speaking in front of people. ??? *Slack* Protip: If you want to convince/influence the audience – stand up! Especially when others are sitting. Standing up communicates authority and confidence, makes you visible, grabs all attention, puts your body language in use, boosts your voice, improves brainwork. That works subconsciously and is in our DNA – kids look up to their parents; Kings and Popes preach from the tower, etc. In practice: When I enter a meeting room, I always stand somewhere in the corner, ready to jump into the conversation. Don't tell anybody, ha-ha! : - ) If you want to send a signal that you're "at the same level" – e.g., during the interview – sit down and make sure there is nothing in between you. Remember Julius Ceasar and his Round Table? Moreover, if you want a person to feel safer and be on the same page with you, you can touch a person – high five, shoulder tap, etc. Body contact releases oxytocin – comfort, safety, and liking hormone. Warning: carries cultural risk; don't overuse it :-) -- background-image:url("") ####
Your communication skills ??? you already know how to boost them – teaching, expressing your thoughts concisely :) --  -- ####
Your EQ -- - The art of managing your mind, thoughts, and emotions; it’s also your ability to “connect” with others. --  --- class: last-emphasize-h4 ### Am I a good leader? -- ####
How successful is your *team*. -- ####
How successful is *each individual* in your team. -- ####
How is your work appreciated by others. -- - Your teammates. -- - Your manager. -- - Your fellow leaders. -- - Your customer. -- ####
Health checks for Teams and Leadership (Spotify). --  -- ####
Employee turnover. -- ####
People lining up to work with you. --- class: center, middle ### 🍿 Team Leadership in the Age of Agile #### **dev.tube/video/sSdMcqxkEdo** --- class: center, middle ### 🍿 Leadership Guide for the Reluctant Leader #### **dev.tube/video/3PcL8UkorEg** --- class: center, middle, strongy # **You made it!**
??? - You'll need some time to digest things. - I'll also need one day to recover and then get back to you in Slack :-) --- ## Let's stay in touch: ###
twitter.com/eduardsi ###
linkedin.com/in/eduardsi ###
goodreads.com/eduardsi ###
eduards@sizovs.net --- class: center, middle # Q&A ??? Masterclass is short, career is long. What if we connect on socials? Share your social profiles here. :thread: :finish: As promised, I’ll keep responding to your questions and participate in conversations until Friday afternoon, and then disappear silently : - ) For those who don’t have any questions – thanks for attending the masterclass, and let’s stay in touch! P.S. this Slack will remain active. So you can keep conversing here even after I leave. Oh, one more thing: I need ~4 more course recommendations for my [principal.dev](http://principal.dev/) website. If you enjoyed the course and have something good to say – please DM or email me the text – I’d happily add it to the website (eternal fame guaranteed : - )