Thread by @wiredferret

Hey, friends! I’m at #LeadDevNewYork. I’m going to be trying to get my livetweeting mojo back, so I encourage you to mute the tag if you don’t want a firehose of conference content.

First up, @nerdneha! Building Culture Through Communication.

Why focus on communication? Because communication and team culture can’t be decoupled. There’s no way to make them separate.

#LeadDevNewYork @nerdneha You actions aren’t louder than your words, they only speak as loud as your words. The way you communicate reflects your culture. Not communicating is the communication.

#LeadDevNewYork @nerdneha How can you see signs of a culture in communications. Is this what you want to be telling people, with both your message and your messaging.

#LeadDevNewYork @nerdneha If you want to be clear about anything that has a time (everything), group the dates together, make the times clear, INCLUDE TIMEZONES.

#LeadDevNewYork @nerdneha Neha is going through an email about a team member leaving — emotional cue, date in the subject, personal message, manager’s context and vulnerablility, affirmation that people are more than just their value to this company, a section for ?s

#LeadDevNewYork @nerdneha Make sure you include a tl;dr section (YES — I do this in talks all the time)

#LeadDevNewYork @nerdneha Comms from Culture: Good things start with intentionality. If you wanted your team to look at comms and pick up on certain values, what would they be?

#LeadDevNewYork @nerdneha Create an imaginary “panel” of people that you’re writing to, people or personas who you want to be communicating with. New joiners, non-engineers, “leadership”. I can change based on what I think those people want, but I can also ask real people.

#LeadDevNewYork @nerdneha When you ask people for their feedback, it’s a low-pressure way to connect with people and get their feedback. Ask: What is your takeaway? What should I change?

#LeadDevNewYork @nerdneha Use consistent language, including emoji cues to help people know what to expect or what the “official” take is. It adds an emotional and visual layer to your words.

#LeadDevNewYork @nerdneha “Anytime I hear the words ‘I was surprised by’, I know we’re entering a feedback conversation.”

It’s maybe embarrassing to have a catchphrase, but maybe that predictability is reassuring if it usually ends well.

Make commitments to be clear about agendas and don’t mix the signals. I try to be clear about what is going to happen. Don’t ambush people with org changes when they were expecting just another daily meeting.

#LeadDevNewYork @nerdneha Have a comms plan, especially for types of comms that happen more than once. Onboarding, departures, cyclical events. Have a consistent checklist, and when it’s refined, create playbooks for everyone to use.

#LeadDevNewYork @nerdneha Comms playbook
- what’s the intention
- who’s affected?
- where can I get more info?
- when
- tips (thank you, faqs)

#LeadDevNewYork @nerdneha /fin

#LeadDevNewYork Usha
The clean code protocol

#LeadDevNewYork Clean code is code that is easy to read and does what you expect.
Clean code is good conventions and standards, but that’s not enough. You can cleanly use 3rd party services, write great functions, and use SOLID.

#LeadDevNewYork To introduce clean code, you can’t just buy everyone a book, you need to build a continuous culture of clean coding, but making a series of small changes and incremental improvements.

#LeadDevNewYork
- Be a clean code champion
- Choose 4 easy wins in your code base
- Set up a periodic clean code learning meeting to teach those improvements
- New code should be clean code

#LeadDevNewYork
Documentation
- Docs should be skimmable
- Document practical, real examples from your own code
- Leverage tools that already exist
- Advertise best practices!

#LeadDevNewYork Education needs reinforcement. Lead by example, make clean code a part of code reviews.

#LeadDevNewYork When it comes to introducing new practices, culture building and education go a long way! /fin

#LeadDevNewYork @larissar @rncintra Instilling the built-in quality mindset into a dev team

#LeadDevNewYork We need to take small steps to do culture change. (I am sensing a theme in these talks)
- start with a very small habit
- increase your habit in very small ways
- as you build up, break habits into tracks
- recover slips quickly
- be patient

#LeadDevNewYork @rncintra @larissar Built-in quality is a lean management practice of proactively applying quality principles and preventing issues.

#LeadDevNewYork Why is built-in quality important?
It allows you to prevent and address issues collaboratively and systematically through an organic approach.

#LeadDevNewYork
5 dimensions
- code quality
- release quality
- flow
- architecture and design quality
(I missed one)

#LeadDevNewYork
Flow is how work moves through a system. Early feedback, test pyramids, continuous delivery pipeline, release on demand.

If you can’t do releases without pain, you can’t use flow to increase quailty.

#LeadDevNewYork We need to automate as much as possible about tests, and then don’t need to repeat tests as I increase the complexity past unit.

Getting feedback as early as possible depends on continuous deployment so I can get feedback asap.

#LeadDevNewYork System quality is driven by BDD. It’s not only about test automation, but a description of how everything actually acts, in isolation and together. CI/CD is a core requirement for being able to get fast feedback and automating and then testing rapidly.

#LeadDevNewYork
- quality is everyone’s job
- testing should be small, frequent
- test automation focuses on regression testing and as a pyramid
- quality tests a functionality or product
- quality is an incremental exercise
- make mistakes as soon/early as possible

#LeadDevNewYork
It’s not WHO does QA, it’s a WE effort
Quality needs to be infused through your whole organization, a continuous feedback loop linked to your CI/CD.
Pay attention to ops and user feedback to improve quality
We’re building software to be used, not to test perfectly

#LeadDevNewYork The base of your pyramid should be automatic, automated unit tests, and each level of the pyramid assumes the code has passed previous levels.

Manual testing should be able to focus on exploratory testing, not toil.

#LeadDevNewYork Leading a team into a bulit-in quality journey
- build culture first, tools and frameworks second
- automate everything that you can
- identify bottlenecks and work to solve them
- help your team build data and metrics that will identify baseline and show progress

#LeadDevNewYork
[cont]
- normalize feedback and communication
- small victories will compound
- any transformation requires empathy, which leads to culture change

#LeadDevNewYork @krsanford
Software estimation - embracing nuance and controlled chaos

#LeadDevNewYork We are all bad at estimation! All of us.

#LeadDevNewYork An estimate is a guess. A target is the outcome we want. A commitment is a promise of what will happen.

Targets and commitments are not estimates.

#LeadDevNewYork Control what you can, like the magic triangle of timeline, features and budget.

(fast, cheap, and right, pick two)

#LeadDevNewYork Improve your estimates by including a range. Ranges communicate risk and uncertainty.

#LeadDevNewYork Estimation errors:
- uncertain requirements
- omitted/forgotten activities
- subjectivity and bias
- off-the-cuff estimation
- unwarranted precision
- mythical man month - effort vs duration
- peer pressure
- everything else

#LeadDevNewYork Ask for time to think about estimates, instead of just saying a number, because people will often take a casual estimate for a commitment.

#LeadDevNewYork People mistake precision for accuracy! Big round numbers help convey the fuzziness of an estimate.

#LeadDevNewYork What can help? - count and compute what you already have - use historical data - ask for help with expert judgement - decompose a big problem into sub-estimates - use a proxy to guess.

Basically, start anywhere, do science on how wrong you were, iterate.

#LeadDevNewYork
- don’t estimate in a vacuum
- things WILL change, plan to adapt
- be willing to throw it away
- question your parameters
- identify and communicate risks
- the definition of done is a negotiation

#LeadDevNewYork @sarahm Harrassers Are Nice To Me

#LeadDevNewYork When I was younger and earlier in my career, I dealt with harassment over time. That experience faded over time. I thought I had found the perfect company, no one harassed me, they all seemed great!

#LeadDevNewYork What I realized is that the people who could address problems don’t know that there’s a problem. Because the junior people think that it might not be safe to say so, or that everyone knows and has chosen not to act.

#LeadDevNewYork The more power you have in an org, the less bad action you’re going to see or have directed at you. Harassment is about power-over, and the bad actors don’t have power-over senior people, even if there are other dimensions of power.

#LeadDevNewYork People who have been in privileged positions don’t know what bad action looks like, “I’ve been a straight white guy my whole life. Nobody harasses ME.”

#LeadDevNewYork Harassment and bullying are not easily defined, and they seem innocuous to the people who are not the target. It might include unwanted invitations, weird attention, unwanted touching, and unwanted online interactions.

#LeadDevNewYork How do we make it easier to have people talk to us?
- publically ask for help and conversations
- hold skip-level meetings at least quarterly
- welcome and cultivate 1-1 relationships with junior ppl not in the chain
- talk about inequity

#LeadDevNewYork
Most important and hardest:
Be unsurprised when you hear about a problem with someone that you like or are friendly with.

#LeadDevNewYork

How do you know it’s working?
- Do my junior people talk to me?
- Do junior ppl who aren’t in my chain of command coming to me (reputation)
- Are teams talking about power dynamics proactively?

#LeadDevNewYork @Geek_Manager

My Monolith is Melting

#LeadDevNewYork @Geek Manager Let’s talk about legacy. We don’t all have the benefit of starting greenfield. Lots of us work on massive, monolithic systems.

#LeadDevNewYork @Geek_Manager I’ve worked on things so legacy that they’re vintage. I started working on systems that had uptimes longer than I had been ALIVE.

#LeadDevNewYork @Geek_Manager How do we move from these massive, slow systems to CI/CD? Well, it’s not a battle. Change is not war. You don’t win if you DEFEAT your coworkers.

#LeadDevNewYork @Geek_Manager Melting monoliths takes concerted effort on technology, process, and culture.

#LeadDeveloperNewYork Let’s start with process issues: slow releases, change approval boards, lots of manual work.

If you’re scared to touch something, it’s a negative form of legacy.

#LeadDevNewYork @Geek_Manager Change approval boards are organization scar tissue. Change approval checklists are regression tests expressed in PROCESS rather than CODE.

#LeadDevNewYork CABs are people have SEEN SOME SHIT, and want to make the pain stop and not make users do testing in production involuntarily. Deployment is hard and manual and drives bundling because it hurts to deploy.

#LeadDevNewYork We need to stop fighting and start winning back the trust that we (or our predecessors) have rightfully lost.

Win trust by fixing our stuff first. Make releases less dangerous, make testing automated and trustable.

#LeadDevNewYork Get to the point of atomic version control. Set up infra/config as code. Make it possible to stand up high-fidelity environments. This is all possible, no matter how old and weird the system is, if you work toward it.

#LeadDevNewYork Environmental replication is not just about configuration, but realistic data and accurate representation of what actually happens.

#LeadDevNewYork Don’t try to plan every step of your transition, accept that platforms and practices will evolve as you move toward a goal, and they will fit the reality of the organization.

#LeadDevNewYork Don’t wait for permisson to improve things. Adopt a “boyscout” rule to leave things better than you found them. Build improvement into your feature work.

#LeadDevNewYork Look for strongly coupled bits of your architecture and work to make them more loosely coupled, because then you can make safer, more incremental changes.

#LeadDevNewYork Monitor all things! You can apply modern tools to even the oldest, crustiest monolith to learn what’s going on inside them.

#LeadDevNewYork It’s easy to move to releasing more frequently when you’ve made releasing safer and less risky. You have to build a lot of trust before you can change the culture.

#LeadDevNewYork Culture: part of having a division in the world between greenfield and legacy monolith organizations is thinking that engineers are different. But they aren’t. We all want purpose, autonomy, mastery, and inclusion.

#LeadDevNewYork Get your teams focused on the same goal, and make sure that it’s well-defined and clear that it fits with values.

Enable ways of working that people are proud of, both the process and the product.

#LeadDevNewYork People who can be themselves at work and be successful are quantifiably more productive.

#LeadDevNewYork The unit of delivery is the team, not the individual. Treat the team as a unit that can be empowered and useful.

#LeadDevNewYork Legacy systems are still there because they’re delivering value every day. They’re worth caring about and caring for, and learning to create good experiences around them. Systems last a lot longer than you expect. Build robust shit that keeps going.

#LeadDevNewYork When I join an org, I go look at the checklist, because it shows me everything that has gone disastrously wrong for an org in the last 10 years. /fin

#LeadDevNewYork @vaidehijoshi The Death and Life of Great Software Teams

#LeadDevNewYork Jane Jacobs was loud, assertive, and deeply committed to the preservation of Washington Square Park.

#LeadDevNewYork She wrote a book called The Death and Life of Great American Cities, an exploration of how people interacted with their spaces and their cities.

#LeadDevNewYork Having more surface area for people to interact with allows them to have more kinds of intersections with both the environment and each other.

#LeadDevNewYork Codebases are like cities, and our codebase is where our community lives. How can we increase the places for people to intersect in our codebases, like they can in a livable and diverse city?

#LeadDevNewYork Vibrancy comes from a density of people. More context and more use cases are like people who pass through the park during different parts of the day.

#LeadDevNewYork When we see the value in creating a neighborhood or community that can support many kinds of inhabitants, we can also see how that applies to a team with a variety of contexts, perspectives, and experiences. We have to foster and cultivate healthy interactions

#LeadDevNewYork @frankieisfrank Paying down management debt without burning out

#LeadDevNewYork To prevent burnout, you must accept these two facts:
1) You cannot control everything
2) You will never reach the end of your to-do list

#LeadDevNewYork
To prevent burnout, you must respect your own needs and RUTHLESSLY prioritize the things that you can control.

#LeadDevNewYork The first stage of Maslow’s hierarchy, as seen in dev groups, is day-to-day operations. What are engineers doing now or next, and how do they surface real-time informaton to decision makers.

#LeadDevNewYork Layer 2: Product direction. What is the product roadmap. How is your relationship to product management, and how can you improve it?

#LeadDevNewYork Layer 3: Performance management. Is your team on board with the company direction? Are they set up to succeed? It is not always your job to retain everyone, but to build a safe healthy team.

#LeadDevNewYork Layer 4: Organizational Management: Are your teams structured properly? Do you have enough headcount?

#LeadDevNewYork Capstone: Technical debt: This is not the least important, or least urgent, but selling this change to a non-technical decision-maker goes better if you have all the information from previous layers.

#LeadDevNewYork @SaunakChakraba1 Why Most Migrations Fail

#LeadDevNewYork Most engineers learn about migrations the hard way…. the very hard way. It turns out that it’s not that simple.

#LeadDevNewYork Infrastructure migrations are the most complex to manage. All the stuff you need to write the code that is not actually writing the feature, like k8s, platforms, and IaaS, is super complicated.

#LeadDevNewYork Start with a concept, then scale up. If an idea works, does it work across more complex and larger systems? And can we clean it up and make it technically healthy? because at maintenance phase, it’s harder to fix it.

#LeadDevNewYork Post-lunch talk time! WHEEE!

#LeadDevNewYork @tsunamino Corpse Party Bugs

#LeadDevNewYork I… I think this talk is actually about insects, not software bugs! I am strangely intrigued.

#LeadDevNewYork “This one time at CSI Camp….”

#LeadDevNewYork The whole point of that experience was that eyewitnesses are terrible and unreliable. BUT insects are physical evidence that is very predictable in timing.

#LeadDevNewYork “Next up is my favorite decomposition stage of all, it’s called Black Putrefaction!!!!”

(Words cannot convey how enthused @tsunamino is about this)

#LeadDevNewYork @hapamezzo Camille Emefa Acey Don’t squander your inheritence: expert advice for taking over existing teams

#LeadDevNewYork Starting at a new team is like showing up to a new school and hoping you can figure things out. Starting as a manager is even harder, because you can’t be anonymous.

#LeadDevNewYork New manager worries: What are we supposed to be working on, are we working on it? Why or why not? Who seems friendly? etc

#LeadDevNewYork 3 A’s for the Early Days:

- Assess - give yourself time to dig into what’s going on and figure out how all the pieces fit together
- Aim - once you have the lay of the land, you can address low-hanging fruit, align the team
- Achieve - move forward!

LeadDevNewYork - Assessing is about being a curious explorer, seeing the lay of the land and the way the team works. Meet people as early and often as possible and LISTEN.

#LeadDevNewYork Meet with your team when you can and be sure to give every single person individual time to talk to you and tell you their goals and needs.

Meet with your horizontal peers to see what they think about your team.

#LeadDevNewYork Don’t form an opinion yet! You don’t want to prematurely commit to a take on anyone.

#LeadDevNewYork Meet with your boss and get info on what they need and expect, what success looks like. Be sure you keep a neutral opinion about all of this. Act ignorant, ask silly questions — this new-kid privilege is brief, but useful.

#LeadDevNewYork Check out the product! Understand things from the user’s point of view so that you can use “out sight”, because you don’t have the habits of the company yet.

#LeadDevNewYork To learn process, shadow people as they do their job. You’re not trying to make them nervous, just understand what their day-to-day looks like.

#LeadDevNewYork Now that you’ve assessed, take aim. What is foundationally and functionally needed to get to where you want to go? Processes, tools, knowledge and skills, new roles, cross-team support, risks, dependencies, etc.

#LeadDevNewYork Build a roadmap and project when you can reasonably deliver some wins. Stand firm on what you need to do, because being realistic and doing it will build long-term trust. Find the quick wins to start with.

#LeadDevNewYork Even small changes require intentionality. When you take action in the early days, it’s important to show the why of specific changes and link it to what people told you when you arrived.

#LeadDevNewYork Now that you’ve assessed and aimed, you need to achieve. How you manage a team through your first big initiative sets the tone for how your team works with you.

#LeadDevNewYork Stay focused on your charter statement and be sure that you and the team understand how it’s driving your behaviors and choices.

#LeadDevNewYork Find your assistant coaches — culture carriers, ICs, managers, people who you can bounce your ideas off without them feeling like it’s an obligation.

#LeadDevNewYork Retention is key to success. Give the people entrusted to you time to shine.

#LeadDevNewYork Step 0: Ask — you can’t know everything, and you’re going to have to ask about the team’s history, the company’s plans and attitudes, the team’s goals and expectations.

#LeadDevNewYork @raravena80 Simplify your postmortems and focus on scaling

#LeadDevNewYork A post mortem is something that happens after an event at your company. After outages, incidents, breakages, etc.

How do we improve the post-mortem process to make it easier to write and build and share.

#LeadDevNewYork Making it repeatable reduces the friction of creating the document and conversation. Incident management and incident communication tools help you build the timeline and understand the progress of the incident. Your observability and monitoring tools, too!

#LeadDevNewYork What matters is repeatability, templatizing, consistency, and execution. The goal is learning and growth!

#LeadDevNewYork Marek Kiszkis Sunsetting Legacy Systems: A Story by Netflix

#LeadDevNewYork We like new things! We like building new, beautiful, good things as software engineers…. but the real world isn’t like that. There are a lot of old, clunky systems out there.

#LeadDevNewYork

1)What is a legacy system?
2) Solution: A strangler fig pattern
3) Some dangers

#LeadDevNewYork What is a legacy system? It’s a system that has been superseded, but is difficult to remove because of its wide use.

#LeadDevNewYork I think that legacy systems are old, complex, complicated, and UNSAFE. Why do engineers hate working with them? Because they really are that hard to use and manage, no tests, no monitoring, mixed functionality, you don’t know what will happen when you make a chang

#LeadDevNewYork Working with legacy systems is like slogging through mud of technical debt.

#LeadDevNewYork Legacy systems weren’t born bad, they just get that way over time and in the process of being used.

#LeadDevNewYork So how do we phase out legacy systems, if they are used all over in our tech stack? Strangler fig pattern! We can’t just cut down the legacy tree, we need a clever replacement strategy. We build a new application and start shifting use to it.

#LeadDevNewYork (The Strangler Fig pattern is described by Martin Fowler here: martinfowler.com/bliki/Strangle… Your humble editor suggest that feature flags make this process less dangerous)

#LeadDevNewYork The problems of the legacy application need to get refactored, tested, and cleaned up when we create the replacement application, because we are not going to replicate the previous mistakes!

#LeadDevNewYork We have three tools to increase safety:
Equivalence testing (if there’s no state change)
Retrofitting tests (add the tests that the legacy app doesn’t have)
A/B testing (When interactions are very complex, test both outcomes)

#LeadDevNewYork Now let’s talk about the people involved in deprecation projects. People sometimes want to avoid them to avoid the image of working on legacy systems, but this is actually a new project with well-defined goals!

#LeadDevNewYork There are some qualities we should look for in a deprecation project:
Simplification mindset - Dykstra says that simplicity is the prerequisite for safety
Some people really enjoy untangling complicated messes!

#LeadDevNewYork The other important attribute is communication and social skills. Being able to get other people excited about your cause makes it much easier to get help and buy-in.

#LeadDevNewYork @engineering_bae Fostering Psychological Safety on Distributed Teams

#LeadDevNewYork When someone doesn’t feel psychologically safe on a team, they leave and find someplace that they feel like they can be safe.

#LeadDevNewYork Psychological safety is not avoiding all conflict or agreeing to everything.

Why should you care about that?

#LeadDevNewYork Safe people can improve processes, be engaged, share ideas. We hired smart people for a reason, we should listen to them and make sure they feel listened to.

#LeadDevNewYork How do we infuse psychological safety into our teams? Normalize vulnerability and embrace humility. You don’t know everything, so don’t be afraid to say that to your team. Our job is to find answers, not know them.

#LeadDevNewYork Build trust. Let my team know that they can trust me, and show the team that they can trust each other. Ask what my reports need and then deliver it, or do my best and report when it doesn’t work.

#LeadDevNewYork If someone had told me that trust-building exercises a month ago, I would have laughed, but it really did work for our first in-person meeting.

#LeadDevNewYork Lead, don’t control. Empower people to make their own decisions whenever possible. If their choices don’t work, I remind them that failure is (can be) progress. We are working to find solutions as a team.

#LeadDevNewYork Ask questions. It’s good for a team to see me asking questions and see that it’s reasonable and expected to ask questions. I also ask individual questions: how do you like to be managed? How can I improve your work life?

#LeadDevNewYork Setup 1-1s. This is especially important, especially when we’re remote. Even if it’s not all work, it’s building a connection and adding context for our relationship.

#LeadDevNewYork If they don’t have anything they want to talk about, you can ask about their “happys” and “unhappies”. I also ask them about what motivates them and how they would feel more engaged.

#LeadDevNewYork Build gratitude into the fabric of the team. Dedicate time to compliment each other into our retros. This lets me see the dynamics I may be missing from a remote manager perspective.

#LeadDevNewYork When someone is operating at peak performance all the time, they don’t get praise for it, because it’s normal now. Appreciate your team and members all the time.

#LeadDevNewYork Encourage honest and direct feedback. It’s hard, because our brain sometimes sees critique as an attack, and we freak out. But direct and honest feedback goes a lot better if you have built the trust and affirmation before I try to do anything threatening.

#LeadDevNewYork You CAN be both honest and kind. Doing preparation makes this easier to execute.

#LeadDevNewYork I only give constructive criticism in public if it’s a behavior that affects the team’s psychological safety. If that behavior happens and is corrected only in private, it feels to the recipient like nothing happened to fix the problem.

#LeadDevNewYork Do what you can to make a distributed team feel connected with each other. Have a fun channel/watercooler place to talk. Do cameras-on meetings when possible/safe. Try structured fun time.

#LeadDevNewYork Within meetings, leave time for informal chats if the team seems into it. Try to meet in person at least twice a year — it really helps the online communication feel more human.

#TheLeadDev Thank you all for following along with this tweetstream of Lead Dev New York 2022!