Today’s a big day – episode 31 of Developing Leadership is out, where you’ll hear me in conversation with Eiso Kant (CEO & co-founder, Athenian) and Jason Warner (MD Redpoint, previously CTO at Github, Canonical, Heroku).

I’m so grateful for the opportunity to discuss what leading with spoons really means: how I lead and get results by helping others discover and honor their own greatness.

Eiso and Jason were amazing – I always learn something new from them, every time, so I do hope you’ll check it out!

I’m also excited to share that I’m kicking off the search for my next leadership role!

Please read more about me, what I am looking for, and testimonials from my work this year below.

About me

Summary: I manage managers, Staff+ engineers, multiple teams, mission-critical teams, parts of orgs, DevOps teams, Platform teams (directly and managing EMs). I’ve led teams that plan and ship new product lines at two companies. I’ve also managed managers that lead established teams for core infrastructure. As an engineering leader I create and teach processes for inclusive interviewing, performance management, scaling/growth, career development and career ladders, capacity planning, and budgets. I’ve led teams with some of the following primary tools and technologies: Python, Ruby, JS, Mobile dev (iOS and Android), Kubernetes, Kafka, Terraform, and a bevy of AWS.

Creating teams of owners

I focus on outcomes, not output, and create teams of owners who deeply understand the mission and how we’re making a difference for our community of users and customers. I lead engineering so that everyone sees the value, every day, of both building a strong company and creating an amazing legacy for themselves. I coach managers to guide every engineer to be able to articulate how every ticket supports our OKRs and makes a real difference for our customers, while also helping them grow and stretch as ICs.

Building real trust and safety in engineering

Every company wants empowered engineers, but trust is the foundation for empowerment — and many teams lack trust. I’ll teach your managers and leaders how to foster trust with my suite of tools around recommended best practices for 1:1s, career development frameworks, performance management, feedback, career ladders and visioning, capacity planning, and more.

Championing the customer

I started my journey tech years ago in front line tech support, and I’ve retained that empathy and passion for the customers since then – from working as a developer to leading orgs as a Director. (I’ve actually been customer-obsessed for way longer, as a small business owner, but we can talk about that over coffee.) I’d love to work for a company that is truly committed to providing a delightful and unique customer experience.

Fostering blameless learning culture

As someone who has always myself to a high standard, I am a devoted student in the school of self compassion; science and psychology have shown us that we learn and grow best when we feel safe to screw up. I champion experimentation and learning from incidents, and show managers how to offer the same for their engineers.

Hiring diverse teams

I have a proven track record building diverse and inclusive teams with world-class technical hires. But I don’t just get folks in the door, I create environments where they feel heard, valued, respected, and want to stay. And better still, I recognize talent and have directly and successfully advocated for the promotion of multiple stellar engineers and managers from underrepresented backgrounds.

Building the structures for enhancing and sustaining diversity

Not only will I directly hire and promote diverse teams, but I’ll teach all of engineering how to change the way they interview to be more inclusive, create better candidate experiences, and get better outcomes. I align with People/Talent and the leadership team to change the actual processes for our company. In my most recent role, I wrote, introduced, and directly trained ~100 managers, directors, and engineers on a new engineering interview format that we used in a growth period when we added ~100 more new engineers, managers, directors, and contractors. If diversity and inclusion is one of your company KPIs, you want me on your team.

Bringing proven DevOps experience

As a leader, I’ve been putting the recommended practices and principles of Accelerate to work for over five years and have some wonderful stories to tell about breaking down silos between dev and SRE, enhancing ownership, creating SLOs, SLIs, and SLAs, reducing toil, and seriously paying down tech debt while shipping every day. I’ve also been on call, served as release manager, and organized incident reviews to support our learning culture.

Leading tough conversations with compassion

Not many managers can say that when they’ve had to let someone go, the person responded with “thank you for all you’ve done to help and guide me. It’s been so evident that you wanted me to win” — but I have. I take my responsibility seriously, I introspect deeply, and I lead tough conversations with compassion — which is why Lead Dev asked me to teach their course on managing underperformance.

Nurturing and retaining Staff+ Engineers with real career paths

From my first Director role, I’ve been fortunate to manage some very senior engineers — so I’ve long since internalized the need to nurture them and provide real career paths. (I wrote a whole post about it that was featured on Software Lead Weekly!) I’ll work 1:1 and with cohorts of Staff+ engineers to ensure that they are engaged, connected, and have satisfying career paths, and with engineering leaders to update or create relevant career path frameworks, ladders, etc.

Coaching managers

In my role, it’s not enough to do all of the above on my own – I must grow others. I scale my leadership by teaching the managers and senior staff who report to me, and other managers in the org, how to do the same through by meeting in 1:1s, leading manager cohorts, and providing mentorship.

Leading remote teams

Yes, I’ve been doing it for more than five years.

And doing it all with heart

I’m an earnest, kind-hearted soul from the south (USA). My accent and my gentleness, and my own disinterest in self-promotion, have caused a few folks to overlook me. But make no mistake, I am a transformative force with the track record to prove it. I can help you create and foster the culture of your dreams. If you’re ready, let me know!

What I’m looking for

So now you’ve heard what I offer. What am I looking for?

• An executive leadership team that is introspective, listens, welcomes feedback, and seeks to grow. I will have to give you difficult feedback about your teams and practices, and I want it to be treated with care.
  
• A product leadership team with a vision and execution skills that wants to truly partner with engineering, design, and user research to create delightful customer experiences. I often have to play a significant role in product leadership, visioning and execution alongside my engineering duties. I would love to work with a strong Product team.
  
• A culture that understands that we can do best for our customers if we do best for our people. You offer competitive salaries, benefits, inclusive healthcare, time off, professional development, and more.
  
• Integrity is #1 – I will listen to and learn from diverse voices who speak truth to power, and I will create and protect spaces where they are heard. I don’t command and control and you won’t be able to command and control me.
  
• Interview process – I expect the interview process to be humane and truly focused on getting to know me and finding mutual fit, rather than putting me through arbitrary tests. I have years of experience writing interview materials and training engineering orgs around reducing bias in hiring. I expect to speak with my direct manager, a VP of engineering, someone from Product leadership, a leader or IC in Design, and an executive. I expect to be interviewed by those who will report to me (non-code test; again focused on how we’ll actually work together). I can move quickly, but we shouldn’t rush.
  
• Work-life respect and balance – I work (very) hard, but I don’t want my work to be my life. I need time to rest and restore – to work in my garden, be a great partner, cook, make music, and write. I don’t have work Slack or other apps on my phone – I create systems where that’s not necessary. When I disconnect at the close of my workday, I’ll see you tomorrow. I’m based in Nashville, Tennessee, USA.

Thanks so much for reading. If it sounds good, please contact me here, on Twitter at @adriennefriend, or on LinkedIn.

PS: Here are a few things folks who worked with me in the last six months have to say about our work together:

EM: “There is so much from you to steal. All of the decks you’ve put together, the doc templates, the types of questions you ask. I’m just really going to miss that. And I just wanted to share my favorite memory of you, somehow you discerned that I like pie and you sent me a pie and it was the biggest surprise and also the best pie.”

Staff Engineer: “Thank you so much for being there for me. For listening to me complain about things. Not just saying ‘oh that’s nice’ but actually coming back and saying ‘and this is how we are going to fix it’ and then immediately putting together a plan. It was such a transformative difference, I wasn’t even expecting it. But now I will.”

Senior EM: “I think you’re exceptional and I’m frankly jealous of the people who report to you, because you really support them, hold them accountable, and you show how much you care the whole time.”

Director, QA: “There was a tough situation that you came into. I was always inspired with how you took control of that situation and did the right thing. And also when we talked, you were just really kind to me, which was really refreshing. I felt like you saw me and all the work that I’ve done here. And you did it in a really warm encouraging way.”

EM: “You’ve been a great influence on me, I’ve been really honored to work with you, and you’ve really helped me in my career. Your attention to detail, knowledge of different processes, empathy for different people — these are all things I want to see in the executive team and upper leadership.”

Senior Product Manager: “I was not your PM counterpart, but seeing you from across the org, it was amazing to see your leadership, how much you cared, how much you advocated for your teams, how much you advocated for the engineering org, and how much you listened. I think that’s a big theme. You really listen in a way that I haven’t seen before.”

Test Engineer: “If I had a concern, though something could be improved, you were someone who listened to me. I appreciate the pride you took in your work, how much you wanted to improve the engineering org as a whole. I think you really left an impact here. You really set the standard of your position really really high.”

Senior II: “After your boss left, I thought maybe there’s going to be some friction and adjustment period. But the moment I met you I felt like ‘I need to stand up a little straighter, pay a little more attention, have more sense of urgency—and I don’t need to worry. Because Adrienne is going to be focused and she is going to make me focused.’ You do set high standards for yourself and everyone around you, and you are able to do it in a way that is very loving. That is a theme that I keep hearing. You are always actively supporting people and expressing that care and genuine human compassion, very openly, and that makes it so much more satisfying to work with somebody who also wants you to drive and deliver and be urgent. That is a rare combination.”

Staff Engineer: “There was, not too long after you started, a tough situation that you helped me though. I really want to double down and say thank you for that.”

Staff Engineer: “I feel incredibly lucky to have reported to you, I’ve learned so much from your management style.”

Senior EM: “I appreciate your deep level of thoughtfulness in communication, how you handle things. Every interaction I’ve had with you has been deeply thoughtful, considerate, planned and organized. You have this uncanny ability to be fully present in a meeting and chatting at the same time to the point where you are basically completing our sentences for us as we are thinking of them. The concern and care that you show for your teammates and for the people you have brought into this org and mentored, I hope to become that for others.”

Staff Engineer: “You’ve put in a lot of work and effort to create relationships here, to provide that space and trust and safety in your managing relationships, and that is very rare. That is really rare. You care deeply about your people and it shows.”

Today I’m leading a session for Lead Dev Together on what makes a good process. LeadDev Together is a seven-part virtual event series featuring talks and panels from engineering leaders on topics like building motivation, increasing alignment, leading big projects, and building inclusive companies. Each session gives you and your team the opportunity to discuss what you’ve learned in a structured manner, using prompts, exercises, and discussion questions provided by speakers.

I am fortunate to get to kick-off the third part of the series on defining, refining, and aligning processes. I get to ask “What makes a good process?” and dive into three aspects of a good process that I’ve identified.

There’s still time to get a ticket to Lead Dev Together, which gives you access to all of the content, including a recording of my talk and my discussion questions. Today on the blog I’m sharing some new writing on process, inspired by that question: what makes a good process? Hope you enjoy it!

—

“I hate process.”

Have you ever heard anyone say that? I have. It’s a little surprising every time I hear it, because it’s so broad and vague. It’s kind of like saying “I hate books”. Or “I hate music.” Okay… but what kind? And in what context? Can you give me any more detail?

In my experience, people who say they hate process have worked in toxic environments where “process” emerged from a host of dysfunctions. They’ve worked on teams where slow, inflexible, and bloated processes festered in disorganization and bad leadership. On unhealthy teams, processes are scapegoated as the problem, when in reality process is undermined by other big issues, like micromanagement, pervasive fear and threat, poor communication, bullying, failure that leads to blame, poor inter-team dynamics, low alignment, and favoritism, among others. Ugly stuff.

So when I hear someone say “I hate process”, I get curious. Do they really hate the process itself? It’s possible, especially if the process was created without their input or buy-in and couldn’t be changed or challenged. I get it: I’d wither too.

But more often than not, they don’t hate the process: they just hate the way it’s been applied on teams they’ve been part of. They hate not having a say. They really hate what they’ve seen as waste: wasted time, communication, and cycles. Process is just an easy thing to blame: “if only our process had been better.” But this misses the point. Healthy processes rarely emerge from toxic environments.

The “by and buy”

The good news is, it doesn’t have to be this way. You can create processes that aren’t bloated, bureaucratic, inflexible, and full of waste. You can create, maintain, and modify processes that have buy-in and work for your team. You do this by asking the people closest to the work what’s working for them and where they need change.

I call it “the by and buy”: the process is created by the people who use it, and as a result, it has built-in buy-in. The first aspect of a good process is that it is created for and by the people who use it.

the Sharp End

Here I want to introduce an analogy from practitioners of resilience and safety in complex systems. In their book “Behind Human Error”, authors David D. Woods, Sidney Dekker, Richard Cook, Leila Johannesen, and Nadine Sarter identify groups of people called “the sharp end” and “the blunt end”.

At the sharp end, practitioners, such as pilots, spacecraft controllers, and, in medicine, as nurses, physicians, technicians, pharmacists, directly interact with the hazardous process. At the blunt end of the system regulators, administrators, economic policy makers, and technology suppliers control the resources, constraints, and multiple incentives and demands that sharp-end practitioners must integrate and balance.

At the sharp end, we have the practitioners: those closest to the work, doing the work. At the blunt end, we have the folks who dictate resources and constraints. When you see “sharp end”, think of the developers, designers, and DevOps engineers on your team: the people closest to the work, doing the work. When you see “blunt end” think of the managers, VPs, and executives: the folks who have historically been able to exert out-sized influence on products and processes, without feeling the direct pain of implementation.

And yet, the sharp end do so much more than just follow rules and processes.

(They) resolve conflicts, anticipate hazards, accommodate variation and change, cope with surprise, work around obstacles, close gaps between plans and real situations, detect and recover from miscommunications and misassessments.

Even when that’s not necessarily part of their job description.

Our folks on the sharp end, then, are the best equipped to tell us what is and isn’t working in our process and suggest changes and improvements. It’s likely that they’re already working around certain processes (or lack thereof) in order to get their work done. Inviting them to be co-creators of process with us just makes good sense.

Let’s partner with our “sharp end” to create processes that have buy-in and really work for all of us. The question for those of us on the “blunt end”: will we willingly cede our “power”, accept influence, and listen? We will put our ears to the ground, provide institutional support, and change as a result?

The word “change” is a good transition to the second aspect of a good process.

A good process is changeable.

As engineers, we understand the importance of building “change tolerance” into our software. Fundamentally, we understand and expect software to change.

In an article on Design, Jim Shore, author of The Art of Agile Development, defines high-quality software architecture this way:

“A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.”

And in their book Implementing Lean Software Development — a book about process – Mary and Tom Poppendieck say it well:

“Almost everything we know about good software architecture has to do with making software easy to change.”

Let’s apply the same principle to our processes. Like software, let’s expect them to change. Like input from our users, we’ll receive feedback from our teams and organization about what is and isn’t working. For our processes to have continued buy-in, they must reflect the changing reality of our teams and goals. As our teams grow and change, we must examine our processes and be willing to change them.

A good process is documented.

Software and processes both create artifacts of our work together. One artifact of software is code. One artifact of process is documentation. We can build in both change tolerance and inclusion by taking the time to document our processes.

Documenting our processes means writing down how we want to work together in the interest of consistency, transparency, and visibility. We don’t have to write long and overly formal documents. And we certainly don’t need to nail them to the door. Let’s instead create useful guiding artifacts that reflect our goals and values that we can look at when it’s time to reflect and change.

Taking the time to write these artifacts helps us, but the impact is felt beyond our team. This is because documenting the way we work together makes our work more accessible to folks outside of our team. Documenting our processes means taking the time to write playbooks, onboarding guides, tutorials, and SLAs. It means making it clear how to contribute to our work, what steps to take, how to file an issue, and where to go to get help. When we do these things, we write documentation. And when we write docs, we make it easier for others to join us.

These things do take time, but the investment yields big gains in our alignment as a team and org.

A good process has reflection and evaluation built in.

Our willingness to put in the work to create healthy, useful processes leads into the third aspect of a good process: our willingness to reflect and evaluation. Before change, comes thoughtful reflection. Here I think of the analogy of a code review or Pull Request.

When someone requests our review in Github, we don’t just open it and immediately click “Request Changes”. Nor do we rubber stamp it with LGTM. Instead, we take the time to read the PR, try it out in a test environment, and leave comments. We do this because while it might seem quicker to skip the work, we’ll have a higher rate of error and misalignment, which causes us to move slower.

Our processes deserve the same kind of thoughtful review. Because they are created for and by the people who use them, and reflect the changing reality of our teams and goals, we must be willing to build in time to reflect on our processes and consider how they are and aren’t working for us.

Talk one-on-one and talk as a team, too. You can use part of a 1:1 to discuss with your manager if a particular process is causing you pain. You can use sprint retrospectives or incident reviews to discuss how certain processes were part of the problem or solution. I also recommend that managers schedule time quarterly to meet and discuss larger team processes as a group.

On process… and writing this doc

In closing, I want to share a little story from the process of writing this doc. I wrote it as I’ve written many others: in a Google doc. I titled the doc “On Process” and the date, which made me laugh… because about ten years ago when I was writing my Master’s thesis I created a Google doc with basically the same name, but in a very different context. My Master’s thesis was on process philosophy, and in the context of the seminary where I earned my degree, on process theology. 

Process philosophy is based on the premise that reality itself is dynamic: that we experience our world and ourselves as continuously changing. Process points to the “processive” nature of Being or Existence, or how we are always changing and growing. In process philosophy, process is not a dirty word, nor is it something to fear or minimize. Instead, process is something to embrace, because it is our reality.

It’s not worth it to fight reality and the inevitability of change. When I create and evaluate processes, I’d rather embrace my lived experience. So I remember that all processes are above all by and for the people who use them: created by us to support us. It’s why I work to ensure processes are easily changeable–which coheres with reality itself, not to mention the principles of good software architecture. And finally, it’s why I build reflection and evaluation into the processes I manage, so that we are routinely and intentionally asking if the process still serves us. Things change, after all.

I went to a liberal arts school and a seminary, where they prided themselves on teaching us how to think, not what to think. If we cultivate these four healthy attitudes about process, we’ll avoid dogmatism and dysfunction and create supporting structures that make sense. In doing so, we’ll create a process that not only works for our teams, but in a deeply philosophical and metaphysical way, coheres with (one view) of reality itself. And how cool is that?

Thanks for reading.

Special thanks to my friend Matt Davis, known on Twitter as @dtauvdiodr, for introducing me via his work in the resilience community to David Woods’ concept of Sharp End / Blunt End.

Today, it’s been five years since I hosted Atlanta’s first two-day Python programming intensive for women: Django Girls ATL. Since then, the women, coaches, and I have all grown so much.

I hope you’ll join me in revisiting the post I made then and celebrating how far we’ve come.

But today I also want to share a story from that day. Something I’ve talked about in keynotes — PyOhio comes to mind — but isn’t too widely known.

The night I launched Django Girls — after months of solo effort — I was crying in the bathroom because I found out I didn’t get yet another job as a developer.

Yeah.

You see, my goal was to make Django Girls Atlanta the friendliest, most supportive, and most caring introduction to code these women could have. I wanted to give them the Cadillac of coding workshops. I wanted them to have the world! I found the most empathetic coaches. The coolest space. The cheeriest decorations. The best prizes, before prizes were even really a thing. And of course this former chef would make sure the food was incredible–it was! You read the post, right?!

Django Girls Atlanta really became a model for other Django Girls events in many ways.

I wanted to give the women a Cadillac experience because I felt like that was the kind of introduction to Python they deserved. If they were going to do the hard work of learning to code, I was going to try to make them feel as supported and comfortable and safe as possible.

Django Girls was a truly special experience for me that I am so proud of. Many women went on to become full-time developers. It was a huge success. Looking back from five years, I am in awe.

But here’s the part of the story you haven’t heard–very few people have.

At the same time that I was learning to code and running PyLadies ATL and giving presentations at PyATL and planning Django Girls Atlanta… I was also trying to get my first job as a developer. Because of course I was! It was my dream!

I was a career-changer doing phone screens and tech interviews and in persons and building and deploying projects. I’d interviewed a lot over the last few months and was so full of hope that my dream of becoming  a developer would soon come true. After all, I’d quit my job six months prior to pursue this dream, and was living on dwindling savings. I even asked friends for help with my rent at one point.

Django Girls was a two day workshop. The first night everyone gathered together for a big meal, party, and time to set up your local dev environment. The balloons were blown up, the decorations were just right. People were arriving all smiles, so excited to get started.

Coaches were rolling in, too. And one of the coaches was the hiring manager for a job I’d just had an in-person interview for. I wanted this job so badly y’all! I hadn’t heard anything and it had been about a week, so I asked him about it.

We stepped into the hall. I could see our students excitedly meeting each other and the coaches. Squealing about the cute decorations, the cupcakes I’d made from scratch just that morning. Joy was in the air.

And he let me know that they would not be moving forward with me.

I was crestfallen. I remember exactly what I said:

“Ok, I understand. Thank you for letting me know. And thank you for being here tonight to coach Django Girls. I think it’s going to be a wonderful experience for so many and I’m glad you’re part of it.”

He thanked me too and went back inside.

I broke down. Sobbing, I rushed to the bathroom. I didn’t want to be seen. Minutes before our amazing workshop, I was crying in the bathroom, feeling like a huge failure.

Feelings I’d been struggling with for a while surfaced violently. Through PyLadiesATL and Django Girls I was devoting myself to getting other women excited about learning to code, saying “you can learn to code! You can change your life!”

I was telling women they could learn to code and change their lives and get jobs as developers…and yet here I was, jobless.  Just a learner with a blog and a willingness to spend all her free hours organizing coding meetups and workshops. Not “successful” in the way I wanted to be: as a developer.

I wrestled with this. Obviously, I wasn’t successful. But I held tightly to this belief, this hope, this faith, that if we all just kept working and supporting one another we would eventually get there together. If we had each other, we’d be okay.

And so I dried my eyes, went back into the workshop, and gave the women that Cadillac experience I’d planned.

We had a wonderful two days together. I checked in with each of them: how are you doing? How are things with your coach? Where are you in the tutorial? Can I get you anything?

And though I’d planned every little detail, it wasn’t the fun decorations or the tasty food or the cool space that the women kept bringing up to me. Of course they said they were thankful for these things. What they kept saying was how warm and welcoming I had been to them. How safe they felt. How I really made them feel like they could do this.

These women had no idea that the night before I was crying in the bathroom because I didn’t get a job as a developer.

I didn’t need to feel conflicted about encouraging others to pursue something I hadn’t yet done. This “problem” was merely an opportunity to be honest with others about how hard it really was. And in being honest, I could build an even bigger community.

I became an early advocate of talking openly about just how hard it is to learn to code. Of being real about the journey, and using frank language with each other about how challenging it is. How painful it can be. How isolating it can feel. How vulnerable you can feel asking for help. And why, because of these things, it is so very important to be supportive of the courageous people who are doing this very very hard thing.

So many people related to this message. More people spoke up, talked about how hard it had been for them. People who were struggling and frustrated felt comforted. More people felt willing to take the risk to learn. And so our community grew.

I share this story because my success and growth has always been inextricably intertwined with giving back & helping others. At every step as I sought to advance, I wanted to bring others with me. Even in the earliest, hardest, gnarliest and most hopeless days.

And you know what?

It was completely worth it.

Did you participate in Django Girls Atlanta 2015 and want to update the community? Please message me on Twitter at @adriennefriend, or use my Contact page on this site to give me an update. I would love to hear from you.

As an engineering manager I’ve been fortunate to manage some extraordinary senior engineers: folks I personally looked up to prior to managing, recruiting, and hiring. (I’m not naming names in this post, but you can check my LinkedIn for ideas.) Over the years I’ve learned a few lessons about how to support them. It’s different in some key ways, but familiar and constant in others.

This blog post is for engineering managers who find themselves managing very senior engineers and want direction on how to be more effective. Read on for a compassionate dose of reality and actionable advice. 

Senior engineers are humble… but they still appreciate appreciation. 

In my experience, some of the most senior folks you will work with are also the least showy. You’ll rarely hear them crow about their accomplishments, despite the fact that they have accomplished a lot. And some may even seem to shy from the spotlight.

None of this exempts you from making sure they hear that their contributions matter. There’s no “one size fits all” when it comes to thanks, so take time to learn their appreciation style and communicate in a way that is meaningful to them. Ask how they feel valued, make note of it, and follow up. Some senior engineers need to hear “thank you” and a few words about how they made a difference. Others feel appreciated when you take something off their plate or take time to break down a big project with them. You won’t know unless you ask.

They do NOT expect you to be the smartest engineer in the room… but they do expect you to show up for them. 

Very senior engineers know better than to expect that you’re the smartest engineer in the room. You’re not the first EM they’ve had, and they’ve already seen how hard it is to balance contributing code and managing a team and how badly that can go (and likely, they’ve had to do it before, too). Their long career means they’ve seen a lot of dysfunction and have a keen sense of what they will and won’t tolerate on a team.

This means they expect you to be a strong leader for the team and address issues as they come up. Support your seniors by leveraging your strong communication skills to address and heal team dysfunctions and increase collaboration and alignment toward shared goals. Behave ethically and communicate transparently. Use your 1:1s to let them know what’s going on with the company and the team. Ask for their expertise and take their concerns to heart. 

And when they make a request of you, take them seriously. As I said, they’ve been around the block and know what they want. This is awesome because your senior is where she is because she is flexible, adaptable, great to work with, and has made a great name for herself through collaboration and excellence in her work. She’s a delight to work with and she doesn’t make too many demands. So when she does make a (rare) request, take it really seriously and show the heck up. 

Senior engineers know their work style… support it, even if it challenges your ideas about “how work gets done”. 

Senior engineers have been in the game for a while and know their work style and preferences. For example, one senior engineer I managed stressed the importance of Deep Work time. (I even read Cal Newport’s book Deep Work for better ideas of how to support them!) Another very senior engineer said they needed meetings to be scheduled, rather than ad hoc. When your engineers share their work style with them, it’s important to take them seriously. Remember, they know these things because they are accomplished professionals who have figured out how to be effective.

Managing exceptional individuals means expanding your ideas about how work gets done. It may mean flexibility on hours, location, co-working spaces, blocks of time unavailable, etc. When recruiting these folks, be realistic about what your company can and cannot offer in this area. (Don’t pitch your team as flexible if it isn’t.) This may mean challenging your preconceived notions about “how work gets done”. Allow yourself to be challenged. The trust you build in the process will be your reward. 

Senior engineers have seen some stuff… promote safety on your team by encouraging them to share their stories.

If you’re working on a team of mixed levels (very senior and very junior) it’s very common for the junior folks to be nervous about making mistakes in front of the very senior folks. This is not weird or unusual: most people don’t want to look stupid or careless in front of people they respect. And while this isn’t obvious to more junior folks, senior engineers know in their bones that they got to where they are by trying lots of things… and making lots of mistakes! Honor your senior engineer’s experience and humanity by encouraging them to get real with the team and tell their stories.

Build safety into your team by inviting your senior engineers to talk about their own growth path. When they share how they deleted the prod db (that didn’t have backups) it helps your team by humanizing them and making them more relatable. It reminds those junior folks that seniors are not infallible, and that making a mistake is an occasion for growth, not punishment or shame. It also helps the senior engineer by driving home that this is a team where it’s still safe to grow–where learning and experimentation is actively encouraged and rewarded. Taken together, this means a better connected, authentic team. 

Senior engineers have a LOT going on outside of work… make room for it on your team.

Senior engineers often get to where they are not only by excelling in their paid work, but by cultivating relationships and opportunities in our field outside of their day job. They’re mentors, board members, keynote speakers, authors, and open source contributors. No kidding: one developer I managed wrote Essential SQLAlchemy and taught courses for an online platform, while another served on both the Python and Jupyter Steering Councils. Supporting your senior means knowing them as a whole person, being aware of these commitments, and finding ways to make room for their passion at work. 

Why? Engagement. Cultivating a rewarding career or advancement path for very senior engineers can be a challenge for a lot of managers, and so often they just don’t do it… or they do it poorly. But seniors deserve better from us–they deserve the same kind of support we’d offer someone early- or mid-career. 

The thing is, it just looks different. Don’t just take advantage of their decade + experience by only having them cut code. Take seriously how they spend their time outside of work and find ways for them to make an impact on your team doing similar work: mentoring, teaching, writing, leading deep dives, and beyond. If FOSS is important to them and your company allows, support them in open-sourcing and sharing their work. And don’t ever forget that your senior engineer’s dedication to non-profit and open source work outside of their daily routine enriches the whole ecosystem that you live and work in. When they give, everybody wins. 

Related: remember, they’ve got options. 

If you’ve got a highly senior engineer working for you, they’re probably highly sought after. And if their inbox isn’t filled with recruiters, they’re definitely already well-connected. You need to make sure you’re providing an environment where they want to work: where they feel heard, respected, and like they’re growing, too.

That said:

Senior engineers are just like you and me… foster a team where they feel safe to fail, learn, and grow.

The danger of focusing on how senior engineers are different is that it will turn into hero worship, or will paint them as this precious object who needs to be protected and catered to. It will obscure this crucial point: that senior engineers deserve to be treated like everyone else on the team. This means creating a safe place to fail, learn, and grow. As much as you may respect and look up to them professionally, this highly motivated, successful, generous senior engineer you’re managing is still a human.

Being human means doing human things, like making mistakes, saying confusing things and getting frustrated. Your exceptional senior is going to screw up. They’re going to make annoying and obscure remarks. They’re going to have days where they don’t really look very productive.

Just because they’ve had a decorated career or gave six keynotes last year or were Engineering Hire 1 at your org doesn’t mean they don’t still want or deserve the same level of care and engagement you’d give others on your team. This means giving context, coaching, and feedback. I know what you’re thinking: really?! They care what I think? Yes! I can’t tell you how many times senior engineers said they learned something from me: a new way of approaching a problem, a different perspective, important context, etc. (And yes: it feels amazing every time.)

Your seniors are where they are because they have committed to their own growth. Don’t put them on a pedestal or expect them to be self-maintaining. I know a manager who said “I don’t need to do 1:1s with my seniors” because he felt this way. What a missed opportunity. Senior engineers need and deserve dedicated 1:1 time, career conversations, and a place to hear and share feedback. Make sure you are providing an environment where they still feel like they’re learning and growing.

By sharing feedback and context, appreciating their contributions, taking their work style and concerns seriously, and looking for ways to authentically support them, you can create an environment where senior engineers grow and thrive.

Hey everyone, exciting news: I’m looking for a new job! Read on to learn more about me and what I hope to find.

In my two most recent roles, I directly managed the core engineering and Dev/Ops teams and reported to the CTO. I have a bias to action and growth mindset, and work well with leadership that shares these traits. The teams I’ve managed over the past three years have been remote and extremely senior.  For the past five years I’ve also advocated for, mentored, and sponsored early-career and underrepresented folks in tech through a variety of formal and informal initiatives and non-profits. Since 2015 I’ve given over two dozen talks and keynotes to technical and engineering leadership audiences.

I’m looking for a senior engineering management position where I can continue to build high-performing, inclusive teams founded in trust, transparent processes, and creative freedom and ownership. I excel at motivating engineers, increasing alignment, leading difficult conversations, and improving communication and collaboration. My goal is to enable, empower, and inspire developers to do some of the best work of their lives.

If you’re my direct report, you can expect me to bring joy, courage, and safety to our interactions. I’ll listen carefully and take what you have to say seriously. I’ll help you set goals and meet them, and then I’ll celebrate your wins with gusto—or quietly, if that’s more your style. And when we do incident reviews, I’ll create a space where your voice isn’t marginalized and you’re not afraid to share.

I’m excited to get to know your tech stack and tooling, even if it’s new to me. As a docs-taught career changer who went from Python and JavaScript to Kubernetes and Kafka, I’m up for a challenge. I even served as technical editor of a Python textbook! That said, I’ve never aspired to be the cleverest engineer in the room: as a developer, I have a growth mindset and am happy writing readable code, reliable tests, and doing thorough code reviews. Where I really shine is as a people manager, partnering with top engineers to make sound technical and architectural decisions.

I’ve been leading remote teams (across four time zones) for over three years and plan to stay remote, based in Nashville Tennessee. If your team is remote or is transitioning to remote and could benefit from a remote-first senior leader, let me know.

Sound like a fit? Awesome! Please check out my LinkedIn and send me a message. While you’re there, please read my Recommendations, as many are from former direct reports who offered to write about me.

Thanks for reading! Stay safe and healthy.

Hey everyone,

A lot has changed in my professional life in recent months, so I wanted to share a quick update and some ideas about what’s next!

Saying goodbye to Verica

I am no longer working at Verica. I’m grateful for what I learned while directing engineering and ops at a very early-stage startup. Taken with my previous experience leading engineering and DevOps at a mature SaaS, I have a more well-rounded view of the challenges and opportunities of different remote teams–and three years leading them.

Kicking off Lead Dev’s Asynchronous AMA series

As we all grapple with the new reality that is a post-COVID world, Lead Dev is thoughtfully adjusting the way they deliver programming to support their huge audience of tech leads, engineering managers, and CTOs. I was honored to kick off their newest effort, Asynchronous AMA (Ask Me Anything), answering questions like how to get buy-in for 1:1s, how to discuss non-work challenges in light of COVID, and how to go beyond status reports to have meetings that matter.

Speaking at Python Web Conf

I’ve given over two dozen talks at tech conferences around the world, but it wasn’t until June that I gave my first talk at a fully online event: Python Web Conf! I had an outstanding experience. Read my thoughts on this event, and how to evaluate other online events, here.

Giving back at The Collab Lab

As a senior engineering manager working largely with very senior engineers for the last three years, I’d recently been looking for a new way to give back to the community: and I found one! I joined The Collab Lab as a Mentor, leading a cohort of exceptional early-career developers through a fully-remote eight-week intensive where they learn critical collaboration skills while building a production app. I’d love it if you read my recap about the transformative work we did together!

Becoming a Lead Dev author

Yep, the word is out… I’m now a Featured Contributor and Author at The Lead Dev! Over the next year I’ll be writing articles for an audience of tech leads, lead developers, senior engineers, and engineering managers, and CTOs on topics like performance management, compassionate feedback, and fostering a diverse and inclusive team and environment. My first articles will be coming out soon. Edit/update 8/21: my first post is up! Read “1:1 Foundations: best practices for conversations that count” at LeadDev.com.

Moderating Lead Dev Live panel on 1:1s — this week!

Join me and three other experienced engineering managers this Wednesday, August 12, at Lead Dev Live: a free, one-day virtual conference featuring talks and interactive panels from engineering leaders all over the world. I’ll be moderating a panel on 1:1s with Alexandra Sobhani (Google), Kwasi Ohene-Adu (Groovetime), and Spencer Norman (Mailchimp). We met up last week to go over what we’re going to discuss and let me tell you, it is going to be GOOD: we’ve got some amazing tips and resources to share.

And yes… I am now looking for a new team!

I’m excited to find a new senior management role on a team where I can have impact and improve communication and collaboration. Read more about what I’m looking for in this post.

—

Thanks so much for reading my updates! Of course, this is just the professional stuff. Like you, I’ve also been adjusting to life under a global pandemic and quarantine while missing my friends, family, and the most mundane parts of my “old” routine: the gym in the morning, spur-of-the-moment lattes, weekly grocery trips. My father passed away in July–I still don’t have words to describe the loss, but I’m hugely grateful for the outpouring of support I got from my friends in tech. I’m hanging in there, trying to stay positive and do as much good as I can. ❤️

You might recall that in May I joined The Collab Lab as a Mentor, leading a cohort of exceptional early-career developers through a fully-remote eight-week intensive where they learned critical collaboration skills while building a production app. Well, guess what? THEY DID IT!

Shajia, Lily, Ali, and Luka built the product by pairing weekly. They opened, reviewed, and merged PRs. Each week they demoed their work in production in an engaging and thorough way. They were active participants in retros, openly sharing their joys, appreciations, wins, and thoughts on how things could be improved. They attended learning modules to level up on accessibility, effective code reviews, pair programming, and technical writing. Read our cohort’s official recap from mentor Stacie on dev.to.

Not only did they achieve all of the goals of the program, but they also followed the “campsite rule”: they’re leaving the place better than they found it. Yes, the Collab Lab is already a terrific program. But Shajia, Lily, Ali and Luka made it better by flagging opportunities to make the Github Issues and Acceptance Criteria more clear, and by filing new Issues for things we could to improve the program for all future cohorts.

The Collab Lab offered me a unique opportunity to offer the same kind of encouragement, enthusiastic support, clear communication, and compassionate feedback that I’d typically devote to my high-performing professional development teams, but at a non-profit. As a result, these incredible early-career developers now know exactly what it is like to work on a highly effective, psychologically safe team. It’s my hope that Shajia, Lily, Ali and Luka will use this experience as their playbook for the future, because they now know firsthand just how effective a safe, supportive team can be.

BIG thanks to founder Andrew and Stacie for inviting me to mentor, and for trusting and empowering me to lead. We worked great as a team, covering for each other when needed. As I said repeatedly, I am in absolute awe of the quality, thoughtfulness, and intentionality of the program that they have put together and continued to refine. Andrew and Stacie are the real deal, y’all — true allies, advocates, sponsors, mentors, speakers of truth to power. They care like few others, and they put in the work to show it.

So, to recap: would I recommend The Collab Lab? Will I mentor again? A-B-S-O-L-U-T-E-L-Y!

If you’re an early career developer with coding chops who wants to learn the collaboration side of code, you owe it to yourself to apply for the program. If you know someone who would benefit from learning the ins and outs of pair programming and code reviews in a safe, supportive environment, please let them know about The Collab Lab. And if you want to support our work (we are a non-profit!) please support us on Github Sponsors. It’s worth following Collab Lab on Twitter, too.

What’s next for me and Collab Lab? Well, I just can’t quit. I’m joining Cohort 9 as the Code of Conduct responder… and I expect it won’t be long before I sign up to Mentor again.

Recently I gave a talk at Python Web Conf called “The Zen of Python Teams: New Lessons (for a post-COVID world)”. My goal was to revisit the wisdom of the Zen of Python and use it to encourage developers and teams adjusting to working together in our new reality. Here’s how I think it can help.

The Zen of Python Teams: New Lessons for a Post-COVID World

It’s harder than ever to focus at work. Many of us have been thrust into remote work for the first time, or are balancing work-life integration like never before. Those of us who are still working, that is. Many of us have been laid off. And if we haven’t, we know someone who has: a friend, a spouse, a relative. We and our loved ones are dealing with some pretty heavy stuff, and it all makes work harder than ever. Communication is harder than ever. Conflict seems more frequent. We’re tired and stressed.

What could I or the Zen of Python say that would possibly make a difference?

We’re all doing the best we can right now. And I certainly don’t have all the answers, I’d like to try to help. I’m an experienced engineering manager who has been leading remote Python teams for over three years. No, I’ve never faced a global pandemic before, but I have learned some solid lessons about communication and conflict, building inclusive teams and transparent processes, and improving psychological safety among engineers. And reinterpreting the Zen of Python for teams is a strategy that gives me further clarity.

I’d like to help you adopt attitudes, processes, and practices that will help you grow and be part of happier teams who deliver better software, faster. Yep: even during a Global Pandemic. I want to give you tools to improve your communication, collaboration, and productivity so that you can deliver useful software and feel successful and connected during this incredibly stressful time.

Deliver useful software? Yeah. We’re still here to do that. I believe in shipping and the positive feedback loop it creates. This quote sums it up for me, from Intercom’s VP of Engineering:

“Shipping is your company’s heartbeat. Software only becomes valuable when you ship it to customers. Before then it’s just a costly accumulation of hard work and assumptions. Shipping unlocks a feedback loop that confirms or challenges those assumptions. It makes new things possible… (and) brings life to your team, product, and customers.” — Darragh Curran

Don’t forget that a healthy culture is critical to helping engineers ship software in any environment. You deserve to work and collaborate on a team where you feel heard, safe, and respected. And in our current crisis, a healthy team culture is more important than ever. Thankfully, the Zen of Python has lots to say about healthy culture.

So let’s talk about how to build healthy, psychologically safe teams that ship, informed by the Zen of Python.

In this post, I’ll introduce and cover six of the Zen’s famous lines. While these were originally written about software development, I’m interpreting them for teams.

“Beautiful is better than Ugly”

Words like “beautiful” and “ugly” are tricky, because we implicitly understand how subjective they are. That is, they require context to make meaning, and even then we could argue about it: one person’s “clean code” is someone else’s cave painting.

Where I come from, the word “ugly” doesn’t just mean the opposite of pretty. When applied to behavior, it means misbehavin’, being disrespectful, or making trouble. My grandma would say, “Stop actin’ ugly and behave!” Do you believe behavior can be “ugly”?

Have you ever seen “ugly” behavior on your development teams? Actions taken that have caused conflict or pain? Here are a couple of things I’ve seen: hoarding information—that’s when someone knows something helpful that they could share, but they don’t. I’ve also seen bitter, cutting code reviews—when the goal should be to critique code, not cut down people.

This kind of ugly behavior makes me recall Ron Westrum’s typology of organization cultures. Westrum wrote about three types of leadership that give rise to different types of team culture and communication. His types are pathological, bureaucratic, and generative. A team’s type will be reflective in its leadership, the way it approaches problems and conflict, and the way communication flows or does not flow.

We see the most ugly behavior on pathological and bureaucratic teams. On pathological teams, information is viewed as a person resource to be used in political power struggles, and the environment is characterized by fear and threat. People may hoard or distort information, or shy from taking responsibility for their actions, because they are scared. On bureaucratic teams, folks feel more loyalty toward their immediate team than they do toward their company and its goals. They insist on their own rules, on maintaining turf, at the expense of others and the organization.

On generative teams, in contrast, the leader emphasizes the company’s mission and they rally people around that mission. They ask, how can we accomplish our goal together? People feel like they can take risks, because they feel like risks will be shared, and they won’t be scapegoated. Failure leads to inquiry rather than blame or root cause analysis.

Westrum noted that leaders set the tone for their team, but we’re all still responsible for our own actions. So ask yourself, what kind of team do you want to be on?

We could debate “Beautiful” code all day; thankfully, kind behavior is more obvious. Being explicitly welcoming, sharing information freely, and making it safe to fail are just a few hallmarks of a healthy, generative team. In the examples to follow, I’ll cover specific strategies for improving communication, transparency, and psychological safety.

Explicit is better than implicit

Explicit is better than implicit makes me think of how important documentation is. Healthy teams document their processes and expectations. They provide playbooks and resources and onboarding guides and tutorials. They make it clear how to contribute, what steps to take, and what to do when you’re confused. They do this because documenting your processes makes it easier for others to join you.

Without good docs, people who already know each other can probably figure out how to get what that need. That’s because they’re sort of cheating by leaning on existing relationships to get unblocked and get their questions answered. But what if you’re a new person? You don’t have that shared context. You don’t know the back channels.

Documenting our processes makes our work more accessible to people who don’t look like us, or don’t already know us. If you want a diverse and inclusive team, you’ve got to take the time to document your process.

It’s also critical to be explicitly welcoming and clear about what you value and behavior your team will or won’t accept. Write a Contributing Guide for your project that outlines what steps need to be taken to get a PR merged, or how to open an issue, how to get help, or how Code of Conduct issues will be handled. Tell new Contributors explicitly that you want them there and need their help. If you feel your team has an issue with diversity & inclusion, raise it.

Now is the time to be explicit about what you value.

Keep conversation about code in a public place, such as Slack, or on the Pull Request, is another way to lower the barrier to entry. If you use Slack or a similar tool, this means keeping your conversation about code in the main #engineering, #ops, or #feature channels, not hidden in Direct Messages or ephemeral group chats. Putting it in the open also makes it possible for anyone to learn from it, or jump in and help. This kind of documentation and transparency is critical on a remote team.

Simple is better than complex.

Developers build complicated features and solve complex requirements with sets of smaller, more straight-forward features. As humans, we build meaningful relationships and work through tough issues on a foundation of small interactions that increase trust with each other.

Small interactions like getting coffee and catching up. Talking about something other than work or code. Asking about a new game or movie you know they enjoy. Asking to pair program on a hobby project. Sharing recipes.

But wait, you say: we’re all working remotely now! The coffee shops are closed! SOCIAL DISTANCING!! There’s no passing in the hallway or catching up in the shared kitchen anymore. What are my options?

When I manage remote teams, I like to organize something called remote happy hour. Every week we meet for about an hour just to talk about our lives and get to know each other better. It’s easy and relaxing. And alcohol does not have to be involved (make mine matcha, please).

For some people it might feel tempting to skip a meeting like this one because you don’t really see the immediate value, but this kind of interaction counts as a deposit in your emotional bank account that you’re building with your teammates. You’re building that trust and that familiarity that you can lean on when things get tough. Because things will get tough.

“Here’s the thing about real work: it’s messy. It’s continually filled with trade-offs, goal conflicts, time pressure, uncertainty, ambiguity, vague goals, high stakes, organizational constraints, and team coordination requirements.” — John Allspaw

Real work is messy, and its messiness and pressure and ambiguity is frustrating and hard and painful and disappointing. “Real work” takes a real toll in the best of times, and these are far from the best of times. Let’s invest in our relationships and strengthen them. Let’s build up our emotional bank account so we’re ready when the real world makes withdrawals: when deadlines, stress, and team conflict threaten to deplete us.

Our relationships with each other are the most complex and complicated features of our lives. Like software, let’s build them with small but meaningful actions that show we care.

Errors should never pass silently.

With code, we can write more code to raise and log errors.

With humans, we have to rely other humans to tell us when we broke them.

Feedback is the tool we have to help others understand the impact that they have on us. We owe it to ourselves and each other to give timely, actionable feedback that describes what happened and the impact it had. On a healthy team, if someone screws up, they shouldn’t feel like they need to hide it. Or from it. We understand that people make mistakes and feelings get hurt, but we value each other enough to take responsibility for our actions and try to improve.

We don’t let issues pass silently, because we know that letting things pass silently damages trust on teams. The pain of giving or receiving negative personal feedback is only painful in the moment, but that’s temporary. Allowing it to pass silently is something that can accrue and damage teams permanently.

Here’s a tweet I shared about how to respond to a developer who is feeling overwhelmed with shame for making a mistake. In this example, a developer approached me and said: “Oh my goodness, I am so sorry, I broke this thing, I fixed this thing, but I feel awful about it.” They were feeling shame for making a mistake.

But mistakes are normal, and I want folks on my team to feel safe to make them. I said you should respond my listening and hearing them, affirming and appreciating them, and reminding them that mistakes help us grow. I was careful about the way I responded because I love working on a team where we can be open with each other about our mistakes.

It’s a signal that your that your team is on the right track if they can talk about their mistakes. If they’re hiding, yelling “don’t touch my garbage”, that can indicate that they’re scared. But if they want to show you their trash, that can indicate that they trust you.

So be kind to people when they show your their trash. It was probably hard for them. And let’s show enough of our trash that we get so used to it that showing our trash becomes something we enjoy doing.

It gets easier for us the more we do it. And let’s be real. MOST of us have got a LOT of trash right now. Let’s work extra-hard to make it safe to share and be ourselves in this tremendously difficult time.

In the face of ambiguity, refuse the temptation to guess.

When it comes to code, refuse the temptation guess at someone’s motives. Don’t git blame and suffer quietly: you’re only gonna cause yourself more pain! When you see code that frustrates or confuses you, don’t assume that someone is actively attacking you. Humans are complex and their actions are influenced by all kinds of ideas and experience that you may never understand or have access to.

Instead, care enough to ask where they’re coming from, what they were trying to accomplish, why they took that particular strategy. Reach out and offer to listen.

And if you can’t reach out to that person for whatever reason, try to get some context from someone else who might be able to help. Put your questions on the PR, open a Github issue, address it, confront it, be assertive. Challenge directly in a way that shows you care.

Now is better than never

When I was a developer, I had a single sticky note on my monitor. It read: “Doing and being wrong is a lot better than not doing at all.”

It’s something my engineering manager told me when I was being really hard on myself. He said it because he felt like I was holding myself back out of fear of messing up or being wrong. He wanted to remind me that our team, like my development environment, was a safe place to try things and fail.

As a manager, there comes a time in my relationship with each of my direct reports, no matter how senior they are, when I share that “sticky note wisdom” with them. Maybe they’re being too hard on themselves, or struggling to get started. Whatever the reason, encouraging them to “just start” seems to help. It doesn’t matter how many years they’ve been working as a developer, or how much they know about Python.

Everyone benefits, because we all can use a reminder to start where we are. To start, and try, even if we’ll be wrong or fail. We can do this without fear that we’ll be singled out or scapegoated. On a psychologically safe team, we feel safe to make mistakes because we understand that it is part of growth. A bias to action paired with a growth mindset is powerful.

Everything feels harder than it should right now, but we all have the opportunity to start where we are. In each moment, we can decide to be a force for good: for kindness and empathy, for taking care of ourselves, and for encouraging others. Now is certainly better than never.

Thanks so much for reading. How does the Zen of Python inspire you? Let me know on Twitter.

Since March, shutdowns and cancellations related to COVID-19 are our reality. It’s especially clear in the tech conference space. Where thousands of Pythonistas should have been gathering in Pittsburgh for our beloved annual PyCon just weeks ago, we flexed to a small online event. Perhaps most stunningly, conference heavyweight O’Reilly Media recently announced that they’re shutting down in-person events permanently: farewell Velocity, Strata, OSCON.

I’ve given over two dozen talks at tech conferences around the world, but it wasn’t until this week that I gave my first talk at a fully online event: Python Web Conf! Presented by Six Feet Up and some of the IndyPy folks, I have to admit I was a little skeptical about how they would pull it off. How would they bring the same level of energy, professionalism, and attention that I’ve come to expect of an in-person event to a virtual one? Was it even possible?

And that’s from the perspective of a speaker. What about as an attendee? How do you decide if an online conference is worth the time commitment or registration fee? (Yep, while they may not pay for a physical convention center, online events still have costs associated.) What’s the unique draw of an online conference when we’re already spending all day on Zoom calls?

As a speaker and participant, I can confidently say that Python Web Conference was OUTSTANDING and 100% worth it. From start to finish, every interaction I had with the staff/volunteers and attendees was an overwhelmingly positive one. In advance of the event, they mailed me a “swag bag” filled with great stuff: a custom t-shirt, stickers galore, sturdy notebook, even an Adafruit Feather nRF52840 Express. I felt fully supported by the production team as we did the tech test and went live. Big thanks again to Calvin, MaryBeth, Josh, Carol, Paul, and Casey.

Verdict: would I attend again? YES. Would I pay the registration fee to attend this online event? YES.

But what about other events? It seems like a new online gathering is popping up every week.

It can be hard to navigate our new virtual reality of online tech conferences. How do you know if one is worth your investment? Here are some questions to ask, and how Python Web Conf compared for reference (noted with ✅):

• Do they have a strong, clear web and social media presence? ✅
• Is their event website easy to navigate and lists need-to-know information: a useful About page, Speakers, Schedule, etc? ✅
• Did they have a Call for Papers/Proposals? ✅
• Have they published a speaker schedule in advance of the event? ✅
• Do they feature a diverse line-up of keynote and regular session speakers? ✅
• Do they have recognizable sponsors? ✅
• What kind of tech are they using to host/stream the event? Is it accessible? ✅
• If you have to pay a fee, is there a cancellation policy? ✅
• Is registration handled by a legit ticketing service (e.g., Ti.to, Eventbrite)? ✅
• Do they have a Code of Conduct? Statement on Diversity and Inclusion? ✅
• Are you actually interested in the talks? Can you afford it? ✅✅

Of course, there may be other bonuses like an active Slack community, high-quality videos posted online, or a mailed-to-you swag bag (again, ✅✅✅). But this list will definitely get you started. Please let me know if there are other questions you ask to evaluate online events.

I’m so grateful that my first experience with online events was such a positive one. And I haven’t even talked about how my talk went!

Please read my next post to learn how to improve your communication, collaboration, and productivity so that you can deliver useful software and feel successful and connected during this incredibly stressful time.