Thread by @wiredferret

#LeadDevLondon HEYYYYY, I’m in London, at The Lead Dev, one of the best conferences you’ll ever get a chance to attend, and I actually get to tweet it. So if you are not here for that, mute the hashtag and carry on happily.

#LeadDevLondon @vitorreisdev Navigating the Chaos of Scaling

#LeadDevLondon @vitorreisdev When I reflect on all the moments of how hard it was to do the work and also the work to do the work. To be on-call and do interviewing and all the other things that needed to happen.

#LeadDevLondon @vitorreisdev A fictional story of company scaling. Imagine an engineer named Ana. She joins a small company as an engineer. She is excited about learning and the company is in the product-market fit exploration stage. This is the moment to grow as fast as possible

#LeadDevLondon @vitorreisdev Ana has proven that she is trustworthy and she has a can-do attitude, so she gets tapped to become a lead. She has 2 priorities - hiring her team, and figuring out the new product she’s building. Company continues growing.

#LeadDevLondon @vitorreisdev Anna is not the only tech lead who has moved up, but if you lose any of your tech leads, there’s no one to guide that team. So Anna takes on that team in addition to the one she hired on, but this team is entirely unknown.

#LeadDevLondon @vitorreisdev This team is key to the company’s growth, so she needs to promote people to manage the teams she is running. But when a company stabilizes, they focus on optimization, not speed. The teams are at different maturity levels, though.

#LeadDevLondon @vitorreisdev What did Anna do differently than other engineers in her company that got her to manager-of-managers when others didn’t. She had to be at the right place at the right time, but she also needed the following skills:

#LeadDevLondon @vitorreisdev 1) Being self-aware. Knowing when you’re wrong and when your good work is not the work that needs doing. Anna spent time thinking about what success as a tech lead would look like, and how she matched that standard.

#LeadDevLondon @vitorreisdev Most of the time, we are not doing entirely novel work. There are practices on how to be a good tech lead, improve hiring, building trust. We have to be self-aware enough to search out how to be great, and actually ask the people around us.

#LeadDevLondon @vitorreisdev Book reccs: The Making of a Manager. Radical Candor.

#LeadDevLondon @vitorreisdev 2) Be replaceable. Give away your legos. Make sure that the company and the team is not dependent on you doing exactly the thing you’re doing, because if you’re that crucial, you can never move out of that role.

#LeadDevLondon @vitorreisdev When you start adding people to teams and orgs, people get nervous. What if someone takes my job? What if they do it wrong? What if they’re better at it than me?

[I am being attacked]

#LeadDevLondon @vitorreisdev If you want to grow as fast as your company. You have to give away your job over and over again, so you can move to the next thing.

#LeadDevLondon @vitorreisdev 3) Focus on communication. It’s easier in the beginning, when people know each other. Everything that used to come naturally is now a struggle as your scale.

Writing is thinking. Write your ideas and expectations and you should see what you’re doing

#LeadDevLondon @vitorreisdev Writing is not the end of your job. You need to over-communicate. You need to keep repeating the things that matter. If it feels like overcommunicating, it’s probably the right amount.

#LeadDevLondon @vitorreisdev 4) Be efficient with your time. “Tell me how you spend your time, and I will tell you what your priorities REALLY are.”

Reflect on your time and how you’re spending it, and if it’s contributing to your goals.

#LeadDevLondon @vitorreisdev If you look in your calendar, and only you can do the things in it, start training or hiring someone to do the same thing, so you can be replaceble.

[this resonates with SRE/oncall/SLO themes]

#LeadDevLondon @vitorreisdev How do you get better at time management? You anticipate crises that can arise and pre-address them in a non-chaotic way. If a team is full of heroism, their time management and foresight is not good, or maybe possible.

#LeadDevLondon @vitorreisdev Be careful with overstaffing - the mythical man month is still a true concept.

#LeadDevLondon @vitorreisdev If you spend most of your time in meetings, you may have an organizational design problem. Is that contributing value to your goals and outcomes.

#LeadDevLondon @vitorreisdev Chaos is part of the journey of scaling. It feels scary, but as you make peace with it, you can learn to enjoy the ride. Learn to be more replaceable. Don’t let the chaos control you, embrace it and take advantage of it.

#LeadDevLondon @raulchedrese Keeping Your Codebase Fun at Scale

#LeadDevLondon @raulchedrese What does a not-fun codebase look like? It’s slow, it’s hard to work with, it takes hours to build or generate, or requires big risky rewrites, or loss of competitiveness. Fun is an important part of how we feel about working in a codebase.

#LeadDevLondon @raulchedrese The three steps to fun:
Understand the developer experience
Form a vision
Move toward that vision

#LeadDevLondon @raulchedrese Ask your devs how they feel about working in your codebase. That gives you a picture of how people feel about the work they’re doing. And ask what pain points your devs have. Now you have a list of problems, but just solving them is not enough.

#LeadDevLondon @raulchedrese Form a vision — what would an ideal, fun codebase look like. Use that dev feedback to inform the vision. What matters to your devs, and how can you get to the ideal from where you are now?

#LeadDevLondon @raulchedrese Iterate toward the vision. You need to align on priority. Swarm on a single solution and finish it before you move on. This reduces the risk of never-ending projects. Break the vision down into tasks that are well-defined and provable.

#LeadDevLondon @gabs820 Outputs vs Outcomes: Driving and Defining Quality in Software Development

#LeadDevLondon @gabs820 How is Quality Assurance different in video games than “normal tech”. Well, sadly, I don’t play games all day, but also I kinda do.

#LeadDevLondon @gabs820 When I started, I worked on text-based issues on a localized game. It wasn’t very collaborative - we shipped builds and fixes back and forth. It’s disconnected and QA feels like an afterthought. But localization can happen earlier in the process!

#LeadDevLondon @gabs820 When we did a more integrated testing with development, we could give a tiny bit of creative input based on our multi-lingual capabilities. We got great feedback on how well it worked for players.

#LeadDevLondon @gabs820 Early QA involvement also meant that it felt like a new job every day. Each tester had points of contact, either in an area (level) or discipline (skill), so that each area got coverage and expertise without being a big chunk.

#LeadDevLondon @gabs820 Besides functional issues, we also paid a lot of attention to atmospheric detail. How does snow fall off branches? How do bloodstains show up? Immersion was part of the QA team’s purview.

#LeadDevLondon @gabs820 We also did development support - like making sure NPCs don’t end up weird places, or tagging surfaces with different labels.

#LeadDevLondon @gabs820 My role as QA worked well because I had the context of a level. I didn’t have to wait for build drops, I could work collaboratively with the developers and designers to help create and maintain immersion.

#LeadDevLondon @gabs820 Takeaways: Keeping someone in the same area or discipline too long can result in tunnel vision, but switching too often feels disruptive. When you lose a point of concats, you lose context and rapport with other departments. Docs are key.

#LeadDevLondon @gabs820 Investing in QA long-term was more efficient than applying a lot of bodies at the last minute. QA was also very useful in setting up a user-reported issue support forum. We eventually built a bot to sort and triage issues.

#LeadDevLondon @gabs820 Games as a Service is a model that allows games and developers continue to be developed and improved over time with constant updates.

#LeadDevLondon @gabs820 Imagine if your agile sprint ended with a game release! Deliver patches on a regular cadence and fix bugs as quickly as possible, since there’s no reason to delay bug fixes that are approved.

#LeadDevLondon @gabs820 As a quality owner, I validate tasks, both in and out of the engine, manage vendor teams and do test case and test plan creation, triage and escalate issues as needed, and do risk assessment of bugs and improvements.

#LeadDevLondon @gabs820 Quality is not just QA, it’s the entire team. To deliver the best content, we should embody the experience of the end user. There are a lot of ways to define quality — diversity and inclusion, including different outlooks, perspectives, and representation.

#LeadDevLondon @gabs820 For example, Neon, the Valorant character, is a way to connect with other Filipino gamers, and the perspective she brings is not like any of the other Valorant characters.

[I LOVE THE IDEA OF DEI AS QA]

#LeadDevLondon @laveena_18 How to bring a11y into your teams

#LeadDevLondon @laveena_18 How did I get into accessibility?

“The power of the web is in its universality….” Tim Berners-Lee

#LeadDevLondon @laveena_18 There are a lot of disabled people in the world, working, buying things, consuming media. It’s vital that we make it possible for everyone to access what we’re offering.

#LeadDevLondon @laveena_18 When we get it wrong, we’re liable to be sued, and we’re also losing business. When we get accessibility right, we give people power, ability, and connection.

#LeadDevLondon @laveena_18 For individuals without a disablity, technology makes things easier. For individuals with disabilities, technology makes things possible. Disabilities can be temporary, long-term, or permanent.

#LeadDevLondon @laveena_18 How did I come across accessibility as a topic? I was asked and we realized that making sure people can use our products is part of the definition of done, part of how we finish something. Why isn’t this part of our build process?

#LeadDevLondon @laveena_18 Why is a11y important? It affects community, brand, legal protection advantageously. It adds to business value, drives innovation, and extends market research potential.

#LeadDevLondon @laveena_18 Some a11y benefits: You get a wider audience, you get more usability for everyone. It satisfies current and future legal requirements and ethics. And accessibility improves maintainability and efficiency.

#LeadDevLondon @laveena_18 The earlier you add accessibility to your product, you improve maintainability and prevent later expensive technical debt for retrofitting.

#LeadDevLondon @laveena_18 So if there are all these advantages, how do we bring a11y to my team? Because it’s not the easiest thing to get buy-in from teams to add accessibility to early product thinking.

#LeadDevLondon @laveena_18 Steps: raising awareness, informative slides, discuss with stakeholders, work on myself to communicate effectively, not just enthusiastically. Do research and suggest options. Do a survey and report on the product you have.

#LeadDevLondon @laveena_18 Persistence. Eventually I found an ally who could help push this with me.

#LeadDevLondon @laveena_18 To help your team do this, you need to frame this as part of delivering a high-quality product. Become an in-house expert as much as possible. Use research to back up arguments. Understand blockers and deliver solution options.

#LeadDevLondon @laveena_18 When and how do you do a11y testing? Add the requirements of a11y as early as possible, especially if you have a front-end product. Do it in the design/planning sessions, shift the work left.

#LeadDevLondon @laveena_18 Do as much as you can in requirements - you can show that you have clients with disabilities in the scoping progress.

#LeadDevLondon @laveena_18 Budget — you’re going to have to address this, but doing a11y is cheaper than getting sued for not doing it, or leaving out addressable market. There are a lot of good free tools that can get you started.

#LeadDevLondon @laveena_18 What do you include in your report? Areas that you tested, easy wins, scalable/reusable solutions.

#LeadDevLondon @laveena_18 4 principles of accessible content. Is it perceivable, operable, understandable, and robust?

Book recc: The Design of Everyday Things

#LeadDevLondon @phil_bennett CSS: Cascading Support Systems

#LeadDevLondon @phil_bennett Despite the success of some billionaires, we are pretty sure that empathy is a superpower in leaders, and leads to engagement and satisfaction increases in employees.

#LeadDevLondon @phil_bennett You can scale empathy. Dealing with the emotional challenges of 2 people was easy, but 20 is not… as easy. I really couldn’t cope with that level of emotional labor - it was burning me out.

#LeadDevLondon @phil_bennett I reached out to other leaders, who told me that they didn’t struggle as much. I reached out and got therapy. My therapist said “It’s interesting that you’re struggling with 25 reports. That’s the limit of clients I’m allowed to have.”

#LeadDevLondon @phil_bennett I came across a technique called solution-focused brief therapy. It starts with a miracle question. If a miracle removed your problem overnight, what is the first thing you’d notice in the morning? Here’s something that I came up with.

#LeadDevLondon @phil_bennett 1) Ask questions, increase comfort, identify problems 2) Ask what would happen if that problem could be removed 3) Connect and empathize with the problem and the reporter 4) Work with reporter to define a plan to get closer to better state.

#LeadDevLondon @phil_bennett 5) Check in, see if it’s working. 6) If this works for your report, ask them to flow it down to the people that they are dealing with.

#LeadDevLondon @phil_bennett What happened was interesting. The emotional labor didn’t bubble up, it was absorbed in the network of people who report to me. I could sleep again.

#LeadDevLondon @rhein_wein What dashboards don’t tell you

#LeadDevLondon @rhein_wein How do I know if my team is productive or not? It’s an important question, and sometimes we turn to dashboards to answer it. But, uh, it’s not the same as the perception of the team. Perception of metrics is hard. Performance and productivity are hard

#LeadDevLondon @rhein_wein It turns out that perception of productivity is really important. We live in a world where self-percepted metrics are actually as important as “objective” measures of productivity.

#LeadDevLondon @rhein_wein Dashboards don’t tell you about how people _feel_ about what they’re doing. And any metric will change behavior.

#LeadDevLondon @rhein_wein Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.

(everyone games the system, whether they mean to or not)

#LeadDevLondon @rhein_wein Teams want to be consulted about their performance, not informed. Dashboards don’t tell you how a team feels about what they’re doing, and how to make them empowered.

#LeadDevLondon @rhein_wein Avoid vanity metrics by making sure your dashboards have tension - One point is not useful, but if you contrast speed with quality, how do those track? Are they correlated?

#LeadDevLondon @rhein_wein You need to take both your team and your execs with you. You’ll need to educate yourself to do this, but it can really make it easier to change the way you work.

#LeadDevLondon @jenny_sivapalan Scale, Scale, Scale: Lessons from an engineering recruitment drive

#LeadDevLondon @jenny_sivapalan AccuRx was one of the companies that had to scale enormously during the pandemic. How do you hire exponentially, especially if you don’t have a solid existing process?

#LeadDevLondon @jenny_sivapalan How do we get candidates to apply? How do you grow pipeline? We tried 5 things:
- external recruiters
- grow the talent team
- sourcing candidates (hard, unglamorous, essential)
- referrals
- telling people who we are

#LeadDevLondon @jenny_sivapalan We had to change our interview process to be a bit more regular, documented, and accurate. We needed to look at any roadblocks we had to the interview process.

#LeadDevLondon @jenny_sivapalan We needed to get faster, scale out our team of confident interviewers, and make our process well-understood and reliable. We started by updating the experience-based interview and creating a structure and rubric for it.

#LeadDevLondon @jenny_sivapalan We improved our take-home exercise to make it optional, reflective of real problems we had, and tried to be clear about what kind of solutions we wanted. But we also allowed it to be parallel to other processes.

#LeadDevLondon @jenny_sivapalan We did interview training, offered ways to talk about our hiring process, and did mentoring pairs to help less-experienced engineering managers.

#LeadDevLondon @jenny_sivapalan Each engineering manager has an “on-call” week where they are doing the interviewing and hiring, and they rotate so it’s not eating up all their time.

#LeadDevLondon @jenny_sivapalan We wanted to set candidates up for success, so we told candidate ahead of time what the interview process is, what we are hoping to get out of each stage, and how to prepare for it. We got better-quality answers!

#LeadDevLondon @jenny_sivapalan We just put our salaries on job descriptions!

#LeadDevLondon @jenny_sivapalan You can’t fix hiring as a manager alone. It takes a team.
- draw candidates in to apply
- create a scalable, consistent interview format
- give candidates a great experience

#LeadDevLondon @alexandras_dev uilding the perfect asynchronous meeting

#LeadDevLondon @alexandras_dev You cannot just port a physical retrospective to online interaction without change.

(doing a retro on a retro is amazing)

#LeadDevLondon @alexandras_dev We have week-long experiment weeks where the company processes work in ways that are different, closer to some of the ways our customers work, so we maintain flexibility and curiousity

#LeadDevLondon @alexandras_dev We had an async meeting week, but… it was undefined. Some people thought that it was easier to have focus time. It had more coordination overhead. We didn’t know what the “rules” were.

#LeadDevLondon @alexandras_dev If you have async communication, why do we need async meetings? Aren’t they the same? But we noticed that our project checkins were good async. The townhall was good. And we noticed that we already kinda do some async meetings.

#LeadDevLondon @alexandras_dev It’s vital to run good meetings, because meetings are hugely expensive, both in salary cost and in opportunity/focus costs. The meeting has to be worth all that.

#LeadDevLondon @alexandras_dev What IS an async meeting? It has prep to identify timeline, logistics, and expectations. For a retro, write out thoughts by day A, comment and vote about a week later, and day C is video sync retro, 90 minutes.

#LeadDevLondon @alexandras_dev Logistics include where deliverables go, how to comment, what the form and medium for the content is. Expectations set the tone of a meeting and make it more predictable. Think of them as house rules for the meeting.

#LeadDevLondon @alexandras_dev How do you build your own async meeting? Decide where and when interaction is going to be useful, and then put everything else async. Best candidates for async: information pushes, brainstorming, reading. (maybe listening to presentations?)

#LeadDevLondon @alexandras_dev Then you create a timeline. Make a deadline for each step. Give enough buffer time. And if you’re going to be doing any sync meeting, set the time for that.

#LeadDevLondon @alexandras_dev Set and share an agenda, which includes expectations and timelines. Make it easily accesssible by all attendees. Centralize all the info of the meeting in one known place.

#LeadDevLondon @alexandras_dev Benefits of async meetings: More time for thought, context is accessible, timezone inclusive, and less expensive.

#LeadDevLondon @alexandras_dev The benefits of sync meetings: They require less coordination, provide real-time answers, and allow fast-paced discussion. Sync meetings are especially beneficial for relationship-building, like 1-1s.

#LeadDevLondon @alexandras_dev Async meetings are not just for remote teams! The value is persistent across teams.

#LeadDevLondon Alex Canessa Sustainable means performant: How your design, development, and devops could help the planet

#LeadDevLondon Alex Canessa The average website produces 1.76g of carbon dioxide for every page view. Imagine a site that gets 100k hits - that’s 2,110 kg a year. That’s like driving almost 7k kilometers in a car.

#LeadDevLondon Alex Canessa How do you measure that?

WebsiteCarbon!

It measures data transfer, energy source for the datacenter, website traffic, etc.

#LeadDevLondon Alex Canessa Good UX/UI means that a user gets exactly what they need and gets to it right away. SEO optimization means that people aren’t wasting time looking at the pages they don’t need.

#LeadDevLondon Alex Canessa Images are relatively expensive. We can optimize them. Does the image add value, does it communicate useful information, could we use a vector graphic?

#LeadDevLondon Alex Canessa Of course, efficient code matters. You want to make the minimum number of network requests, maintainable and extensible code also reduces file weight and duplication.

Build static pages! Not all pages need to be built on-demand.

#LeadDevLondon Alex Canessa Progressive Web Apps, combined with a static page, cache information. Service workers check for updates instead of automatically pushing/building every time.

#LeadDevLondon Alex Canessa Go as green as you can for hosting and use a CDN, because the closer you are to the user, the less impact you have on the servers.

#LeadDevLondon Alex Canessa A site that is green is very performant and less expensive. It’s easier to sell sustainability if there’s also a financial incentive.

#LeadDevLondon Sadhana Gopal How to built trust as a new manager in a fully remote team

#LeadDevLondon Sadhana Gopal What is different about working remotely in a team that doesn’t know/trust you?

#LeadDevLondon Sadhana Gopal

#LeadDevLondon Sadhana Gopal There are 3 stages to building trust. You understand the company, then the team, and finally yourself. In your first 30 days, work to understand the wider org, get the right tools, build relationships, understand the context of your team.

#LeadDevLondon Sadhana Gopal Some tools that can help: cross-org pairing sessions, 1:1s with people across teams, peer/study group sessions, absorbing documentation and videos the org uses to understand itself.

#LeadDevLondon Sadhana Gopal For the next stage, you want to build engagement with your team. Use async for productivity and sync for engagement. Design a mix of deep focus and deep connect timezones.

#LeadDevLondon Sadhana Gopal Keep the human touch hwith strong team bonding rituals. Meet irl if you can. Lunch-n-learn sessions, gaming sessions, encourage psychological safety.

#LeadDevLondon Sadhana Gopal The third stage is understanding yourself and what you need. Don’t be always on. Find your buddy who you can connect with. Make mistakes, learn, and iterate. Collect feedback and figure out how to make it work for you.

#LeadDevLondon Sadhana Gopal Remote is not just doing all the same things, but on videochat. Design your work with intentionality, with spaces for deep work and real connection.

#LeadDevLondon @d2burke People Building: Career Planning for your Direct Reports

#LeadDevLondon @d2burke The thing about the Great Resignation is that people are not just quitting, they’re growing. People are looking to leave jobs where they are stagnant. They are leaving to grow their careers.

#LeadDevLondon @d2burke If you’re a people-leader, it’s valuable to help your reports continue to grow in their careers. We need to think about employee attrition, succession planning, and our reputations. When a long-tenured employee leaves, you lose so much context!

#LeadDevLondon @d2burke As a leader, your reputation around helping people grow their careers and their capabilities is an advantage in hiring.

#LeadDevLondon @d2burke Understand position. Understand the scope of context and power available, know your level in the expectations at your company, and know your performance and how it matches expectations and opportunities.

#LeadDevLondon @d2burke Plan: Where are you headed? What motivates you? What is your current path, and is it a good fit for your motivations and plan? What kind of SMART goals tie to the company as well as personal growth metrics?

#LeadDevLondon @d2burke Progress: How do you get from where you are to where you want/need to be? As a manager, how do you help cultivate that progress?

#LeadDevLondon @d2burke Design work that is valuable, impactful, and that shows increasing competency. Hold people accountable in the way that works for them and maintains alignment. Reward people in the way they find motivational.

#LeadDevLondon @d2burke One of the fun parts of being an eng manager is reward and recognition, and making sure you’re doing it the way people want. Maybe it’s public, maybe it’s an invite to the cool meeting with more context.

#LeadDevLondon @d2burke When my reports punch above their weight and take on and succeed at reach goals, it empowers ME, it frees me up to work on something else, because they’ve got it.

#LeadDevLondon @d2burke As a part of building people, we need to think about succession. If we plan for it up-front, you’re not locked into keeping someone in their role, and they can grow in the company and we don’t lose their knowledge. But I care about YOU, as a human.

#LeadDevLondon @d2burke I’m interested in building you, and your career as a person. I’ll keep you at the company as long as I can and as long as you’re growing, but people do leave, and that’s ok.

@LeadDevLondon @neilkimmett Scaling your mobile app release process

@LeadDevLondon @neilkimmett We are experiencing a retro moment of how shipping code works, circa the 80s. And why shipping mobile apps is sometimes more like that than web apps.

@LeadDevLondon @neilkimmett What does it mean to ship an app? You aren’t just putting stuff on the cloud. No, you have to go through an app store. When your users want to use it, they download copies from the app store to their phones.

#LeadDevLondon @neilkimmett We need to be a little more risk-averse when we’re shipping apps, because we can’t just SSH into the world’s phones to fix something. And users have a very high bar for qualitiy.

@LeadDevLondon @neilkimmett When you’re shipping an app, you need to actually think about your versioning strategy, preferably before it’s a real issue. You also want to think about your branching strategy - git flow or trunk-based branching.

#LeadDevLondon @neilkimmett We know that continuous delivery makes us safer, but it’s not always straightforward with apps, but we can still work toward that.

#LeadDevLondon @neilkimmett Also, you want to automate some stuff. You don’t want to do things over and over again if you could just script it. You also want to create a release process that is as repeatable as possible.

#LeadDevLondon @neilkimmett Run regular retrospectives on what is and isn’t working for your app process.

#LeadDevLondon @neilkimmett There are two release strategy styles: Feature-based releases. Keep delivering features, release when you’re ready. Good for small teams. But as your org grows, you may find that doesn’t work. Then you may want to try a release train.

#LeadDevLondon @neilkimmett You release on a regular cadence, and if a feature is ready to go, it goes, and if not, it has to wait until the next set release date.

#LeadDevLondon @neilkimmett Using feature flags is the number one tool for making sure you can ship when you need. Your code doesn’t always release when it ships to the app store. Feature flags help massively de-risk shipping to app stores.

#LeadDevLondon @neilkimmett Next tool: Server-driven UI: Take as much of your business logic as possible out of the app and keeping it on the server to make it possible to update things within the shell of the app.

#LeadDevLondon @neilkimmett It might also make sense to build internal tools to manage things that you have a lot of value in. But usually there is a tool that you could buy that does what you need. (runway.team)

#LeadDevLondon @neilkimmett Summary: Start small. Introduce process as you go and as you need it. Add tooling where you need it to manage process.

#LeadDevLondon @annagranta Seven surprisingly simple ways to stem burnout

#LeadDevLondon @annagranta What is burnout? It is when your mind or body try to stop you from harming yourself during a prolonged stress response. It’s not about measurable stress levels, it’s about duration as well.

#LeadDevLondon @annagranta Tips to take a moment to interrupt stress:
1 - breath from your diaphragm, not your shoulders. Rectangle breathing
2 - hug - propioceptive input
3 - share delicious food
4 - move slowly
5 - smell the roses - engage senses

#LeadDevLondon @annagranta

6 - sing (not necessarily well) Activates your ventral vagus nerve. Also immersing your face in cold water
7 - sunshine helps with dopamine

#LeadDevLondon Final talk of the day is by @nmeans, who, as I may have mentioned, is untweetable. But I’m going to enjoy the heck out of it.

#LeadDevLondon Ok, I am very late this morning, I think I paid for my tube ticket 3 times, and I may have caught my train from a different station than the one I entered. Which is to say I am too late to tweet @gojasmineee ‘s talk, but it sounds amazing!

#LeadDevLondon @gojasmineee Yes! Usability means that people can spend as little time and effort as possible completing a task.

#LeadDevLondon @supriyasrivatsa Why we are writing a monolith, not a microservice

Microservices are when your architecture is composed of different services that communicate with each other. A monolith is a structure that is unitary and contains what it needs. And people think of monoliths as difficult to change and fragile.

#LeadDevLondon @supriyasrivatsa Our monolith was old and fragile and we were scared to alter it, so we decided to break it into… another monolith.

#LeadDevLondon @supriyasrivatsa We need abstractions, but they don’t have to be over a network. Networking makes everything harder! Boundaries are hard to define, and you need to give space for the system to grow and evolve.

#LeadDevLondon @supriyasrivatsa Looking at your usage patterns, and see whether you’re making a set of really chatty microservices (I call this pattern ‘distributed monolith’)

#LeadDevLondon @supriyasrivatsa Conway’s Law says that your code architecture tends to mimic your organization structure. But should your codebase? And should the architecture instead drive the team structure, instead of the other way around.

#LeadDevLondon @supriyasrivatsa We decided that teams should own domains, but not necc. a service. This enabled us to build a modular monolith. The modules are abstractions of a domain. Business domains drive modules, and the interactions are strictly defined.

#LeadDevLondon @supriyasrivatsa Monoliths that you hate are monoliths that lack structure. Strongly structured monoliths have many of the advantages of microservices without the problem of network conversation.

#LeadDevLondon @humayrahanif Navigating the minefield of changing working relationships when stepping into leadership

#LeadDevLondon @humayrahanif It’s a bit complicate to move up to being a leader over people who used to be peers. And this seems to be an under-documented topic, we just don’t talk about it. And when I asked about it, my sources said “ahhh”.

#LeadDevLondon @humayrahanif This talk is for people stepping into a leadership role, or are new to a leadership role, or are helping someone in that situation.

#LeadDevLondon @humayrahanif There are a lot of new skills when you move into leadership. We’re used to learning tech skills, but these are a bunch of other skills. Book recc: The First 90 days.

#LeadDevLondon @humayrahanif Stepping into eng leadership means that our roles change. Where we used to focus on contribution and what we make, but when we move to leadership, we switch from being a contributor to a multiplier. So we need to make an environment that helps.

#LeadDevLondon @humayrahanif We also have to spend effort to make sure our team is aligned with the organizations goals.

#LeadDevLondon @humayrahanif Bruce Tuckman defined team organization in the following stages: forming, storming, norming, performing, and adjourning. (We seldom talk about adjourning - interesting!)

#LeadDevLondon @humayrahanif If things go drastically wrong in these stages, it makes members of the team unhappy and causes a lot of friction, and it takes longer to get to ‘performing’. New leads do have responsibility for getting a team through these stages.

#LeadDevLondon @humayrahanif Teams are made of people, the most complicated systems at all!

#LeadDevLondon @humayrahanif People, process, and tools are key to get the best outcomes and results. Everyone comes to work with their own motivations, and the goal for a leader is to help point those motivations in a productive direction.

#LeadDevLondon @humayrahanif Managing the initial transition - sometimes you know it’s coming - I didn’t! First, focus on the people on your team. This is probably not your strongest skillset yet. But you can do it. Start by setting up 1-1s with everyone.

#LeadDevLondon @humayrahanif Sadly, this is not the moment you can fix all the things that have been bothering you. But pick something small that the team agrees should get fixed, then give credit to the people on your team, not yourself. Treat your team with respect.

#LeadDevLondon @humayrahanif Each situation is unique-ish. Everyone brings strengths, weaknesses, and experiences to a position. Try to find a way of working with each member of your team while making sure that you are well-aligned on outcomes and goals.

#LeadDevLondon @humayrahanif While you’re making your initial transition, feedback is essential. You can use both direct and anonymous feedback. But you can ask general questions about how people feel about the team’s work and environments.

#LeadDevLondon @humayrahanif Can you still be friends with your peers? Yes! But you need to separate your friendship from your job responsibilities. So be scrupulously fair to your whole team, even if you like some of them better. Seeming to have favorites is destructive.

#LeadDevLondon @humayrahanif Having difficult conversations are part and parcel of leading. It’s impossible to please everyone, but it’s especially impossible to please engineers. Engineers want to work hard to create something really re-usable, but never want to reuse!

#LeadDevLondon @humayrahanif If you’re making decisions, and you’re getting a lot of pushback, challenge your own decisions as well. We don’t have to have all the answers, but we need to work to find the answers the org needs.

#LeadDevLondon @humayrahanif Content is King, Context in Queen. If people are raising concerns, thank them for saying something. But it’s often something like your team lacking context about why the decision got made the way it did.

#LeadDevLondon @humayrahanif Possible contexts for decisions: cost, time, data, team, benefits, risks, problems, and quality. When you can clarify this to your team you frequently get better alignment, but sometimes people will still not agree with the decision.

#LeadDevLondon @humayrahanif Navigating hurt and resentment - if you’re the one who is picked and someone isn’t, and the one not selected may have some feelings about that. You don’t want to excessively celebrate, or apologize, and let someone feel their feelings for a while.

#LeadDevLondon @humayrahanif Don’t get distracted by the problem teammate - give them some opportunities, but they are not the only member of the team. Maybe they are not ever going to be happy working for you.

#LeadDevLondon @humayrahanif Look after yourself — it’s a different kind of working you’re doing. Your feedback loops are a lot looser. You may get a bit lonely. You do need to vent, but be careful about who and when you vent to. Find a support network outside your structure.

#LeadDevLondon @humayrahanif Final thoughts: Recalibrate your working relationships. Start small and collect feedback to establish your credibility. Form a support network with your new peers.

#LeadDevLondon @al194781 A Commune in the Ivory Tower? - A New Approach to Architecture Decisions

[your livetweeter was distracted by tiny toast and came in late.]

#LeadDevLondon @al94781 Use the Advice Process:
- Anyone can make any decision
- But before doing so, they _must_ consult affected parties and people with expertise in the matter

#LeadDevLondon @al94781 To do this, use a lightweight ADR, which is a template for proposing plans. It’s a decision record that includes a title, proposal, people consulted, possible drawbacks. Then put it in a central, predictable space.

#LeadDevLondon @al94781 Advice from :sparkle: Martin Fowler :sparkle: This could be really slow. You could spend a lot of time asking people for advice. How could we optimize the speed of the ADR?

#LeadDevLondon @al94781 [note to me - Advice Process looks like Rawls’ Veil of Ignorance for tech decisions?]

#LeadDevLondon @al94781 Optimization: Architectural Advice Forum - a weekly meeting of affected parties and advice givers - ops, infra, product management, legal, security, even execs! Present the ADR, take advice from forum.

#LeadDevLondon @al94781 We also look at the statuses of ADRs that haven’t been decided. What is the blocker and can it be addressed or is there a fatal flaw?

#LeadDevLondon @al94781 By wiping the state clean of our understanding of architecture, we can see what needs to be decided.

#LeadDevLondon @al94781 Ruth Malan: In order for an architecture to be successful, it is very much about ensuring that conversations that er needed to be happening are happening - not always initiating them, or helping focus or navigate them, but making sure they happen.

#LeadDevLondon @al94781 It’s easier to read and get enthused about something right up until you try to implement it with other people. People are hard.

#LeadDevLondon @al94781 How do you fail at this pattern?
- Bad decisions - if you, as a former power-holder don’t let a decision you disagree with, you are messing up this pattern. Let it happen and let it be a learning situation for the org.

#LeadDevLondon @al94781 Failure 2: Old guard is the new guard - you adopt the new process, but you realize that all the same people are making decisions, and no new ones.

#LeadDevLondon @al94781 Failure 2: Off-the-grid decisions - when people aren’t following the process and writing an ADR, but are making decisions. Then figure out why they are going around the process and remove that friction.

#LeadDevLondon @al94781 Failure 4: No trust - This only works if people trust each other and are able to be honest about their needs and advice.

#LeadDevLondon @al94781 The whole point of this Advice process is that we need to be able to scale the concept of architecture. We still need architecture, but in the accelerate/ci-cd world, we need to invite more people into the conversation.

#LeadDevLondon @al94781 When you introduce this to your team, lots of other things pop up, and you learn some interesting things about the team and what they think and what their constraints are.

#LeadDevLondon @al94781 Implementation: If you’re an architect, start writing ADRs and seeking advice. Scale up to your team. Teach others in your org and see how it scales.

#LeadDevLondon @jemolova Sorry… you go ahead. The art of making space and claiming space in meetings

#LeadDevLondon @jemolova I spend a lot of time in meetings, and I also spend a lot of time thinking about what makes meetings suck. One of my least favorite things is being stuck in a meeting where 1-2 people are holding court.

#LeadDevLondon @jemolova There’s a lot of importance to awareness and being aware of how much room you’re taking up. There’s a lot of research on this. The HBR found that only 35% of people said they felt able to contribute to meetings every time they wanted.

#LeadDevLondon @jemolova Some people think this is a gender thing, but I think it’s a privilege thing.

If you’re accustomed to being heard, you’ll be more confident using your voice.

#LeadDevLondon @jemolova It can also be a communication style thing. Some people think out loud. It turns out…
Some people talk to think, others think before talking.

#LeadDevLondon @jemolova That difference in communication styles can cause a lot of tension. What are some other things that might help meetings be more inclusive.

#LeadDevLondon @jemolova Running an inclusive meeting:
- make sure everyone knows how you’d like them to contribute
- empower people ahead of time to talk on a certain topic
- outline protocols at the start, and stick to them
- solicit a range of views, and ask for contrast views

#LeadDevLondon @jemolova
- leave space before you move on to the next point. Silence is HARD, but very useful. Leave a gap a little longer than you’re comfortable with.
- Be an ally. Use your voice to make space for others.

#LeadDevLondon @jemolova When I’m coaching people to claim more space:
- before the meeting, find out if there are any places you should contribute
- don’t be afraid to be the circle back person
- and if you’re comfortable, call out interruptions, either in the moment or later

#LeadDevLondon @gusfune Development setup: how an important part of your toolset is often overlooked

#LeadDevLondon @gusfune Managers mostly assume that engineers know how to use their tools. And maybe we should make sure that the dev tooling conversation extends all the way to what the dev is typing in.

#LeadDevLondon @gusfune If you want a great experience for your users and your devs, you need to think about how it’s actually working for them. If, as the Swedish say, there is no bad weather, only bad clothing. And some people are naked.

#LeadDevLondon @gusfune A lot of us don’t think about how we work. Let’s ask “why’s that”? Show me around, show me your thought process. But maybe more importantly, how is your IDE, how is your tooling, is it as frictionless as possible?

#LeadDevLondon @gusfune ”It’s a game changer to have a thoughtful environment to work in. The little things can improve your state of mind, your health, and even your attitude in the end.”

#LeadDevLondon @h_carver Success isn’t repeatable

#LeadDevLondon @h_carver Think about one of your favorite best practices. Now think about a time or place that wouldn’t work.

#LeadDevLondon @h_carver Learning matters a lot in technology. It’s a foundational principle of the Agile Manifesto, but it’s so essential to keep learning to have a learning minset.

#LeadDevLondon @h_carver The rise of the non-traditional dev - people who find that code is their job first, and was never a hobby. This is a great richness addition, but they expect learning to be part of their work, they’re not doing it on their own time.

#LeadDevLondon @h_carver How can we make learning at work useful. Two frameworks: Bloom & ICAP.

#LeadDevLondon @h_carver Bloom’s taxonomy, a pyramid with Knowing and Understanding at the base, moving up to apply, analyze, evaluate, and create. Those are outcomes of how learning has worked.

#LeadDevLondon @h_carver ICAP is about inputs to learning. Passive learning (like reading ) can be enhanced if you do active learning. Active learning can be improved by constructive learning. Interactive learning is building something with another human and talking about it

#LeadDevLondon @h_carver What the ICAP model doesn’t describe is how much the input affects the output.

#LeadDevLondon @h_carver
1 hard falsehood: Learning styles are innate. It’s compelling, but not true
1 hard truth: Boredom is the opposite of learning. We learn this from the affective context model. This is why feelings about what we’re learning makes it sticky.

#LeadDevLondon @h_carver If you feel bored while learning, you’re not learning at all, you’re just bored.

#LeadDevLondon @h_carver There are 3 kinds of things that we learn: knowledge - facts
skills - abilities
wisdom - contextual judgement

#LeadDevLondon @h_carver The three types of things map well to Bloom’s taxonomy. Knowledge is needed before you have skills to do something. Wisdom tells you when to apply those things in context.

#LeadDevLondon @h_carver Let’s talk about wisdom, how we can learn it, how we can fail at it, and what it means. We often try to turn wisdom back into knowledge, but I’m not sure it always works well.

#LeadDevLondon @h_carver For example, common idioms, like “a stitch in time saves nine”, are an attempt to pass on wisdom that was hard-earned to people who haven’t had the experience of (for example) doing a large sewing repair because of ignoring a small tear.

#LeadDevLondon @h_carver ”Move fast and break things” might not work well in a conservative organization. Context matters. Scrum ceremonies aren’t useful if you are doing them because it’s “just what you do”.

#LeadDevLondon @h_carver The wisdom feedback loop: try->fail->reflect->try. Accelerating experience with peer learning, without experiece, you can do simulation.

#LeadDevLondon @johnapost Why mentoring selfishly is better than selflessly

#LeadDevLondon @johnapost It was surprising to me to think of mentorship as an active thing that people do deliberately and not just an automatic thing that happens when people of different experience levels work together.

#LeadDevLondon @johnapost Putting people on a team and assuming they’re collaborating and mentoring each other is not enough, especially now. Presence is not the same as intentional mentorship.

#LeadDevLondon @johnapost Active mentorship is not just expecting mentorship to happen on a team. You go seek it out. There are 2 key ingredients. 1) Mentee initiates the relationship, giving them confidence and control and increases engagement

#LeadDevLondon @johnapost 2) Mentorship can/should cross reporting lines. It feels safer to be mentored by a senior outside of your reporting structure.

#LeadDevLondon @johnapost When I hike, I watch the people in front of me to see how they tackle a problem that I don’t understand how to approach yet.

#LeadDevLondon @johnapost I got surprised with a promotion to management. I felt like I had a grip on software engineering, and project management, but I didn’t have people management. So I resolved to find a mentor for management!

#LeadDevLondon @johnapost It seems boring to say, but practice and experience make this so much easier. The long management loop started to give results. But as I got better, I started to get bored, like I wasn’t making progress.

#LeadDevLondon @johnapost As a mentor, I can practice things that are not happening on my team yet. It’s a win for me because I can understand patterns without it affecting my team. I see mentorship as a key factor of my growth.

#LeadDevLondon @johnapost Selfish mentors get practice, confidence, and understanding of the potential of people. They also get growth and practice and experience.

#LeadDevLondon @paprikati_eng Using incidents to level-up your teams

#LeadDevLondon @paprikati_eng I’ve progressed my career by running toward fires. The moments in my career where I’d taken big steps had all come as a result of incidents. Everytime we solved a hard problem, I became a better engineer.

#LeadDevLondon @paprikati_eng Incidents broaden your horizons. We can’t learn everything down to bare metal, but an incident gives you an urgent reason to dig into a black box that worked… until it didn’t. It’s real world learning.

#LeadDevLondon @paprikati_eng Incidents teach you to build things that fail gracefully.

#LeadDevLondon @paprikati_eng Incidents teach you to make systems easier to debug. Genuinely useful systems are built with empathy for your future, debugging self. Incidents are a great place to start building your library of patterns.

#LeadDevLondon @paprikati_eng When an incident happens, and is bad, the best people flock from all over the org to help resolve it, and you can learn a lot from these experts. Incidents have unusually high information density.

#LeadDevLondon @paprikati_eng How do we make the learning from our incidents useful to the organization.
1) Declare lots of incidents, so you can practice the response
2) By handling things as an incident, you make it public to the company, and accessible to others

#LeadDevLondon @paprikati_eng
3) Encourage everyone to participate. You can either do it during the incident, or as part of the retro.
4) Compile a list of the best incident debriefs you have and add them to the onboarding documents
5) Show your work as you debug.

#LeadDevLondon @paprikati_eng
6) Use public slack channels wherever possible, and have a central location for people to review the debriefs
7) Look out for anyone playing the hero. It’s hard and stressful and can lead to burnout, but it also means that no one else is practicing.

#LeadDevLondon @marcusfgardiner Career Changers: enabling the huge untapped potential in developers from different backgrounds

#LeadDevLondon @marcusfgardiner Most of us wouldn’t let our 15-yo self choose what we do, but lots of us do pick a career around that age. But sometimes we grow up a lot. Sometimes we change. And so do people who change careers as adults.

#LeadDevLondon @marcusfgardiner So why are we talking about career changers? Because we need people. There is a war for talent. So we need to find the talent in new, different people. Like women, who are often motivated to change careers

#LeadDevLondon @marcusfgardiner How do people end up as career changers? Self-study, university, bootcamp, and apprenticeships. Apprenticeships can be for people of all ages.

#LeadDevLondon @marcusfgardiner How do you recruit career changers? Well, how do you recruit now? And is it working? Our recruiting right now is about “screening”, but we need to be looking for people who are motivated, capable of learning, and enthused.

#LeadDevLondon @marcusfgardiner If you’re lucky enough to have a career changer join you, how do you nurture them? Remember that they are not a fresh-faced grad. They know how to work on a team. What they need is protection and encouragement around their tech skills.

#LeadDevLondon @marcusfgardiner Not everyone has a narrative about having always been into computers. Career-changers often have imposter syndrome and worry that they are not technical enough. But this is a career about asking questions, not a career about having answers.

#LeadDevLondon @marcusfgardiner As an organization, ensure that you go all-in. Assembling a cohort is very supportive. Be sure that you’re including them in all company resources. Career changers are motivated, driven, and curious. Build on that, not CS-gotchas.

#LeadDevLondon @ggonchar Engineering a product for diverse markets

#LeadDevLondon @ggonchar Some products, like Slack and Gmail are global and easy to use across cultures, but sometimes you need a customized and specific solution.

#LeadDevLondon @ggonchar Let’s take the differences in markets for cars — in Italy, it’s a Fiat, which makes sense for the narrow roads. In Canada, it’s a Ford F150, because roads are bigger and snow is more of an issue.

#LeadDevLondon @ggonchar If you look at our site, you can see that our offerings are different for France and the Netherlands. We have different sales models in each country, and different attractors. We also show different cars.

#LeadDevLondon @ggonchar How do we do this on a code level? How do you show the widget for zip code in some countries and not others? You want to make sure that each component is divided only as much as you need to meet market requirements.

#LeadDevLondon @ggonchar Choose the right abstractions - local conditions, local components, or local pages/applications. You can mix and match these abstractions in your codebase.

#LeadDevLondon @ggonchar Choose the right degree of localization with the differences and components you have. How do you make that decision? Understand the customers you’re actually building the product for. Connect customers with engineering/product/design AND business.

#LeadDevLondon @rappalappen Key aspects of managing senior engineers

#LeadDevLondon @rappalappen There is a perception that once you’re a senior, you don’t need as much management support, and if you’re managing seniors, you don’t have to pay as much attention. But your senior engineers have a lot of responsibility.

#LeadDevLondon @rappalappen Every relationship between an employee and a manager is unique, but they are all more fruitful with trust.

#LeadDevLondon @rappalappen Senior engineers have Seen Some Things. They have a lot of experience, and they have a lot of education and practice at being managed. They may have grown past the ordinary rituals of management. They may want a more pragmatic relationship.

#LeadDevLondon @rappalappen What if we partner with seniors, instead of managing them. How do we make this happen?
1) Nuture the multiplier effect
2) Decipher organizational complexity. You have context your senior eng may lack.
3) Provide opportunities

#LeadDevLondon @rappalappen When we work with senior engineers to multiply, understand, and navigate their environment, the positive effects ripple through the organization.

#LeadDevLondon @claresudbery Compassionate Refactoring

#LeadDevLondon @claresudbery [Clare has the most amazing boots, you’re all missing out]

#LeadDevLondon @claresudbery Most engineers wish they refactored more than they do. So why don’t they?

Let’s talk about refactoring, what it is and isn’t, why we should do it, and why it doesn’t happen and how to make it happen anyway.

#LeadDevLondon @claresudbery What is refactoring? It’s attempting to make the code easier to understand and cheaper to modify. But refactoring is not just code, but it can also be process and work habits.

#LeadDevLondon @claresudbery What isn’t refactoring? Rewriting a whole system from scratch is not refactoring. Performance gains are not technically refactoring, because it can often be premature optimization. It’s not cheaper to modify because it’s opaque.

#LeadDevLondon @claresudbery Ok, so how do we refactor?
- Refactor as you go (often TDD)
- It’s hard to refactor code that isn’t testable, so maybe that’s the first thing to test

#LeadDevLondon @claresudbery Things that get in the way of refactoring:
- deadlines
- impatience
- perfectionism
- lack of self-belief
- lack of compassion

#LeadDevLondon @claresudbery Guilt, shame, and despair are the worst possible motivators. We don’t feel like fixing things if we feel like we have to fix everything all at once, and we built something kinda awful in the first place.

#LeadDevLondon @claresudbery Lacking compassion is a blocker for refactoring, because compassion mitigates all of the previous problems.

#LeadDevLondon @claresudbery How does compassion help with deadlines? It gives people the strength/ability to ask for more time and an extension of deadlines.

#LeadDevLondon @claresudbery Compassion with yourself lets you break your refactor into small, manageable bits, instead of holding yourself to an unreasonable standard of perfection.

#LeadDevLondon @claresudbery How does compassion help with impatience? Compassion lets us forgive ourselves and each other for not always doing the best job in the first place. Forgiveness lets us move forward without guilt/shame.

#LeadDevLondon @claresudbery Compassion helps with teh drive for perfection. But we don’t identify with perfect people, we look to and want to be like imperfect people who get things done anyway.

#LeadDevLondon @claresudbery When you have crippling expectations of perfection, and you’re scared to make changes, a way to get started is @geepawhill ‘s Many More Much Smaller Steps.

Learn how to make tiny improvements, because that is a compassionate expectation.

#LeadDevLondon @claresudbery If everything you do is easier to understand and cheaper to modify, we all win. It’s easiest when we do it very often, and in very small steps. It’s more likely that we’ll do it from joy and not guilt or shame.