Team Culture

Summarized using AI

Humane Development

Ernie Miller • April 21, 2015 • Atlanta, GA

The video 'Humane Development' by Ernie Miller, presented at RailsConf 2015, addresses the intersection of human elements and software development methodologies. It emphasizes the messiness of human interaction within technical processes and the pitfalls of dehumanizing team members in pursuit of predictable outcomes.

Key points discussed include:

- Responsibility and Accountability: Ernie Miller, as the Director of Engineering at Invisium, shares the pressure and accountability he feels in his role, acknowledging that workplace issues often lead to employee turnover.
- Humanizing Software Development: The speaker stresses that developers and teams are not just resources or abstractions; they are humans contributing to a collaborative environment. He coined the term 'humane development' to encapsulate the idea that software development should prioritize compassion and understanding.
- Agile Methodology Critique: Miller critiques the common adoption of agile practices without their foundational principles, noting how organizations often revert to old processes despite the agile mindset emphasizing individual interactions over rigid procedures.
- Culture of Urgency: He conveys the dangers of working under constant urgency, urging teams to evaluate the actual importance of deadlines and the potential damage of hurried decision-making.
- Importance of Environment and Autonomy: Stressing the need for a work environment that fosters autonomy, Miller highlights how organizations should trust and empower their teams instead of creating constraints.

Miller's insights are grounded in personal anecdotes about experiences that illustrate the emotional dynamics at play within teams. A significant moment involves a previous CEO’s reductive view of team members as mere resources, highlighting the detrimental effects of such an approach. He underlines the importance of connection, empathy, and dialogue to build a healthier workplace culture.

In conclusion, Miller calls for a reconsideration of methodologies that prioritize human factors, advocating for transparency and trust in teams. He suggests that recognizing our shared humanity can lead to healthier environments conducive to innovation and productivity. The discussion resonates with industry trends where employee well-being is integral to long-term success, urging collective action towards a humane approach in software development.

Humane Development
Ernie Miller • April 21, 2015 • Atlanta, GA

By Ernie Miller

Agile. Scrum. Kanban. Waterfall. TDD. BDD. OOP. FP. AOP. WTH?

As a software developer, I can adopt methodologies so that I feel there's a sense of order in the world.

There's a problem with this story: We are humans, developing software with humans, to benefit humans. And humans are messy.

We wrap ourselves in process, trying to trade people for personas, points, planning poker, and the promise of predictability. Only people aren't objects to be abstracted away. Let's take some time to think through the trade offs we're making together.

Help us caption & translate this video!

http://amara.org/v/G6iR/

RailsConf 2015

00:00:12.160 My name is Ernie Miller, and I'm on Twitter at @erniemiller. You probably shouldn't follow me unless you'd like to see my most popular tweet.
00:00:20.080 Feel free to look it up.
00:00:28.640 If you enjoy things like that, go ahead and follow me.
00:00:35.360 I work for a company called Invisium, which is an application security consultancy. I’m the director of engineering there.
00:00:42.000 However, this role does not come with an awesome chair or a megaphone.
00:00:48.000 Instead, it comes with a crippling sense of responsibility.
00:00:54.239 In my previous jobs, I often had a great excuse if I was disappointed in how things worked out.
00:01:00.800 If I felt let down by my managers, I could always say, 'Well, it’s not my fault.'
00:01:06.720 If I wasn’t given free reign, might it be their responsibility?
00:01:11.760 It’s not exactly a proud moment to admit such feelings, but it’s the truth.
00:01:18.000 I don't think I'm alone in this sentiment.
00:01:24.400 In fact, let’s see a show of hands. How many of you have been at your current job for less than a year? Keep your hands up.
00:01:31.600 Now, if you’ve been in your job for less than two years, raise your hands.
00:01:37.200 Look around the room, and realize that half the people here have not been in their jobs for two years.
00:01:43.920 Thank you, you can put your hands down now.
00:01:50.479 When we leave jobs, we take ourselves with us. Most likely, none of us thought we were the problem, right?
00:01:56.799 Sometimes it feels impossible to fix issues at work, and it becomes easier to simply move on.
00:02:03.680 Now, the problem for me as the director of engineering is that I am responsible for the software, the team, and the culture.
00:02:10.399 So it all ultimately comes down to it being my fault if something goes wrong.
00:02:16.400 This is a lot of pressure, so I began to think about what truly makes me happy in a job.
00:02:22.480 What keeps me around, and conversely, what makes me want to leave?
00:02:28.640 Allow me to share a true story, although the specific employer isn’t important.
00:02:33.680 They may not even still operate that way, or if they do, they won't be around much longer.
00:02:39.200 I was brought on to lead a team of technical folks reporting to a CEO.
00:02:45.440 Initially, I was concerned that I'd just end up managing people without writing code.
00:02:51.360 I really feared that would make me unhappy, so I raised my concerns.
00:02:57.440 Fortunately, I was assured that wouldn’t happen.
00:03:03.599 Fast forward about six months, and sure enough, I wasn’t spending much time writing code.
00:03:09.680 In fact, I was triaging a Kanban board full of more urgent tasks than we had people to handle them.
00:03:16.400 This is a glimpse at my actual Kanban board—I'll admit I wasn't very good at it.
00:03:23.200 I was trying my best to shelter my team from the wrath of our formerly jovial CEO.
00:03:30.799 I approached the CEO to share my concerns and said, 'This isn't what I signed up for.'
00:03:36.639 My team is stressed, I'm not writing code, and this isn't the engineering role I expected.
00:03:43.120 To which he replied, 'You're thinking of this all wrong.'
00:03:48.720 He suggested viewing it as just another development task—my team members were objects in the system.
00:03:54.080 He encouraged me to approach this like traditional engineering.
00:03:59.280 But instead of aligning with his point of view, I realized exactly why I was unhappy.
00:04:05.760 The issue stemmed from my boss being a former engineer himself.
00:04:11.040 He wanted to run the company as if it were software, ignoring the human element.
00:04:17.840 But in reality, the truth is: people are not objects.
00:04:24.800 This realization brought clarity to my misery; I was dehumanizing my employees.
00:04:30.039 People were overwhelmed, which led to stress and attrition.
00:04:36.639 We were overworked, and hiring new employees became impossible due to boundaries being violated.
00:04:43.120 I felt like I was the only one who recognized this dysfunction.
00:04:49.199 It felt as if my CEO had a distortion field affecting his perception.
00:04:55.199 Of course, I might be a bit more sensitive to these issues.
00:05:02.000 I've been involved in volunteer counseling for six years.
00:05:08.800 Even prior to that, I've always been a sensitive person.
00:05:16.000 This experience was excruciating.
00:05:21.760 I repeatedly tried to counsel my CEO about my concerns.
00:05:28.000 What I wanted to say was, 'People aren't objects; they are humans.'
00:05:34.560 Ultimately, I chose to walk away.
00:05:40.800 You might consider my example extreme—and it was.
00:05:47.040 But I don't think it's unique. I've seen this pattern before.
00:05:53.440 Business values often conflict with what we value.
00:05:59.040 It values predictability and measurability, often viewing control as the means to achieve predictability.
00:06:05.919 I understand this, as businesses must be able to keep promises.
00:06:12.480 Companies often desire things to be neat and organized, and that’s understandable.
00:06:19.120 But people are messy, and companies are made of people. This does not diminish their beauty.
00:06:26.639 So, how does a company deal with this messy reality? It does so with abstraction layers.
00:06:34.080 They abstract away the human part to shape the outcomes they desire.
00:06:41.440 Humans are reduced to mere resources, metered and applied to problems.
00:06:48.320 For instance, we need a certain number of resources, for a set number of hours, to produce a product.
00:06:54.239 Corporations treat humans as resources, even though the essence of a corporation lies within its people.
00:07:01.120 This reduction of humans to mere values is problematic.
00:07:07.680 In response, I aimed to establish a guiding philosophy for my team.
00:07:13.920 It should acknowledge that we are humans working with humans to develop software for the benefit of humans.
00:07:19.839 This idea may sound simple, but it's profoundly deep.
00:07:25.440 I don’t suggest this is a groundbreaking revelation.
00:07:30.720 However, certain implications naturally arise from acknowledging this fact.
00:07:36.160 I coined the term 'humane development' to encapsulate these concepts.
00:07:41.600 The term 'humane' is defined as having or showing compassion or benevolence.
00:07:48.320 It also means inflicting the minimum of pain, which I aspire to see in my workplace.
00:07:54.480 This may sometimes conflict with our current methodologies.
00:08:01.760 How many of you practice agile methodologies today?
00:08:07.840 Great, let’s see how many of you are truly agile.
00:08:13.440 There’s a talk by Uncle Bob titled 'The Land That Scrum Forgot', which offers interesting insights.
00:08:19.680 He shared a bit of history on the term 'agile' and why it resonates.
00:08:25.680 During a meeting with Martin Fowler, they aimed to establish an organization.
00:08:30.880 From their discussions, they coined the term 'agile'.
00:08:37.440 The idea was to articulate their values without disparaging the old ways.
00:08:43.440 They embraced the Agile Manifesto, which many of you might be familiar with.
00:08:49.679 It emphasizes individuals and interactions over processes and tools.
00:08:55.920 And working software over comprehensive documentation, among other priorities.
00:09:02.720 Kent Beck mentioned that if we are to regard this agile methodology as such, it should bridge the gap.
00:09:09.440 A connection between business and development should be a goal.
00:09:16.640 Shortly thereafter, Ken Schwaber formed the Scrum Alliance.
00:09:23.040 He began offering certified scrum master courses, which became quite popular.
00:09:29.760 However, it was noted that many attendees were not developers.
00:09:36.480 He felt it was silly for project managers to take these courses—just to add 'scrum master' to their LinkedIn profiles.
00:09:42.560 These project managers were not truly fulfilling the role of a scrum master.
00:09:48.160 The idea was meant to evolve beyond needing a scrum master at all.
00:09:54.560 The approach should promote rotating the role among team members.
00:10:00.960 What happened was that companies embraced the agile concept but reverted to old habits.
00:10:06.720 Things gradually shifted back in favor of old methodologies.
00:10:13.200 The focused values of agility became diluted.
00:10:19.520 Many organizations appreciate the term 'agile' because it connotes speed.
00:10:26.080 Speed sounds great, and it’s often associated with the concept of hustle.
00:10:32.960 However, I don't particularly enjoy the term 'hustle.'
00:10:39.920 It's often connected to the idea of frantically working toward success.
00:10:46.400 But let’s entertain a different perspective about what hustle truly means.
00:10:52.480 For one, it implies forcing someone to work hurriedly, which isn't admirable.
00:10:59.440 This should not be a virtue, but in startup culture, it often is.
00:11:06.080 The motto 'move fast and break things' is commonly embraced.
00:11:11.680 It's important to note that this phrase originated from Facebook.
00:11:17.840 However, I argue that this philosophy leads to negative outcomes.
00:11:24.320 We've transformed hustle into a virtue, but it is a damaging meme in today’s software development.
00:11:31.200 We use estimating points to showcase velocity because we embrace hopping from one sprint to another.
00:11:38.720 After each sprint, we take time to rest and recover.
00:11:45.360 While I may not be an avid sprinter, I often engage in high-intensity interval training.
00:11:52.320 This method uses short bursts of intense effort followed by brief recovery.
00:11:58.960 However, sprinting is not designed for sustainability.
00:12:05.280 Instead, marathons focus on maintaining a steady, sustainable pace.
00:12:12.000 In a marathon, the finish line is an abstract concept for a long time.
00:12:19.039 The key is to keep moving sustainably.
00:12:26.720 Rushing toward a finish line can jeopardize future races.
00:12:32.960 It's vital to share the big picture with coworkers.
00:12:40.160 Understanding our shared goals allows for sustainable pacing.
00:12:46.960 A focus only on immediate goals may lead to overexertion.
00:12:53.040 How can we plan for sustainability without a clear idea of the end goal?
00:12:59.520 This brings us to the importance of estimates.
00:13:06.240 A recent snowstorm provided a perfect metaphor.
00:13:12.720 I estimated shoveling my driveway would take about an hour.
00:13:19.200 However, after two and a half hours, I realized my estimate was significantly off.
00:13:25.440 If I can't accurately estimate something familiar like snow shoveling, how can I estimate abstract software projects?
00:13:31.680 Most deadlines are essentially lies too.
00:13:38.560 If we miss an estimate, we just move the deadline.
00:13:44.639 So, why establish a deadline if we keep changing it?
00:13:51.040 Most urgent tasks aren't really urgent, which leads to a critical question: why?
00:13:57.760 The simple question 'why?' can transform requirements into meaningful rationale.
00:14:03.680 It's essential to challenge urgency.
00:14:11.200 When something is urgent, understanding the underlying reason is needed.
00:14:17.040 Urgency shouldn't lead us to overlook our responsibilities.
00:14:24.320 While down systems generate urgency, it’s vital to assess the risks associated with it.
00:14:30.959 Understanding what value is lost is crucial.
00:14:37.040 You may remember from a previous talk how sharing stories about personal experiences enhances learning.
00:14:43.440 While working as a sysadmin, I made a catastrophic mistake due to urgency.
00:14:50.080 In an effort to resolve an email issue, I mistakenly deleted critical directories.
00:14:56.080 I learned that haste often results in irreversible consequences.
00:15:02.960 It’s essential to assess and mitigate impacts when acting with urgency.
00:15:08.880 Moving towards deadlines can produce cascading failures.
00:15:15.040 Nonetheless, defining effective deadlines is crucial.
00:15:22.080 Noting that urgency can lead to unclear tasks is vital.
00:15:30.240 Consequently, we need to interrogate urgency and deadlines.
00:15:38.240 Understand that success cannot be solely measured by progress.
00:15:45.600 Remember, a divide exists—a lie we create; it's crucial we recognize it.
00:15:54.080 This recognition fosters empathy towards coworkers and stakeholders.
00:16:02.239 True understanding requires connection with both business and programming.
00:16:08.240 Openness and visibility lead to pathways for creating a shared understanding.
00:16:15.439 Defining that bridge helps avoid arbitrary deadlines.
00:16:22.080 Investing emotionally and professionally in team dynamics yields important results.
00:16:29.120 When asking why, we should expect rigorous and genuine responses.
00:16:36.960 This honesty encourages equitable decision-making among teams.
00:16:43.520 Creating honest situations fosters better systems and processes.
00:16:49.360 Adhering to dubious deadlines promotes smoke and mirrors implementations.
00:16:56.160 These result in unmet expectations, even if we hit our milestones.
00:17:03.440 Many companies might ultimately fail if they don't recognize and embrace these realities.
00:17:09.760 Furthermore, companies often resort to crunch modes.
00:17:15.679 Employees cram all necessary work into shorter time frames—it’s a reaction to high pressure.
00:17:22.080 However, this should be considered an exceptional measure, not the standard.
00:17:30.080 Much like how we handle code exceptions, we need to analyze the aftermath of crunch times.
00:17:36.960 We don't want to rely on heroes in our teams; we should target prevention.
00:17:44.000 I want to showcase my best code ever, and I’m quite proud of it.
00:17:51.200 It's the kind of code that has 100% test coverage and requires no maintenance.
00:17:56.320 Yet we laugh about it because we understand that not writing code can be the best scenario.
00:18:04.960 Processes, by nature, have maintenance requirements too.
00:18:11.760 We need to be skeptical of our processes as we would with someone else’s code.
00:18:18.320 Adapting processes means ensuring they fit well without overwhelming the team.
00:18:24.800 Processes should never replace trust; they should enhance collaboration.
00:18:31.200 It's crucial to analyze mistakes and address their root causes.
00:18:37.680 Defining a process becomes a last resort.
00:18:44.240 Abandoning processes just because someone made a mistake isn't productive.
00:18:50.960 Processes may become legacy traps, distorting definitions over time.
00:18:59.040 In programming, legacy code often is maintained without questioning why it exists.
00:19:06.960 Although we can rationalize our methodologies, they’re often set without context.
00:19:13.440 What I’m calling process meta programming can help here.
00:19:19.680 My friend, Glenn Vanderburgh, illustrated this ideology with a remarkable analogy.
00:19:25.679 He recounted how his father taught him driving from a handbook.
00:19:31.840 The key takeaway was to drive in such a way that everyone understood your next move.
00:19:37.440 Emphasizing rationale helps elucidate the minutiae and guidelines.
00:19:43.600 If organizations drown in formalized processes, they drown in complexity.
00:19:50.560 This leads to tool development to follow said processes.
00:19:56.320 These tools often shift from reflecting processes to defining them.
00:20:02.720 When new hires enter the organization, they learn the wrongly defined processes.
00:20:09.280 As a consequence, any alteration in processes must begin with tool revisions.
00:20:16.320 Tools should serve as useful instruments and not define the team's future.
00:20:23.040 Small tools allow us the flexibility to adapt without overwhelming the organization.
00:20:29.600 It's integral to empower team members with options.
00:20:37.280 Dr. Martin Seligman—the father of positive psychology—conducted studies on happiness.
00:20:44.320 He demonstrated how people thrive when given choices.
00:20:50.400 However, some environments stripped them of autonomy, often leading to despair.
00:20:57.440 People in power tend to impose restrictions, assuming everyone's fine with that.
00:21:05.920 But autonomy is vital—not merely under the threat of leaving.
00:21:13.680 I’ve seen financial and emotional barriers prevent many from leaving toxic situations.
00:21:22.160 Thus, optionality is essential for individual contentment.
00:21:29.840 When I had to leave, it felt like I was abandoning close relationships.
00:21:37.840 Regrettably, my CEO made me feel guilty for my departure.
00:21:45.920 Often, it’s sad to witness coworkers in distress due to overbearing management.
00:21:53.840 Developers have the potential for flexibility, working in various formats and patterns.
00:22:01.680 The truth is that empathy, honesty, and trust are interrelated.
00:22:08.480 Each one leads us towards greater autonomy.
00:22:14.560 Ultimately, autonomy cultivates the environment for thriving developers.
00:22:20.959 Object-oriented programming emphasizes communication; processes need to encourage efficiency.
00:22:27.760 It’s paramount to lift programmers’ spirits rather than constrain with geographical demands.
00:22:35.840 Increased communication enhances collaborative capabilities, even from a distance.
00:22:42.480 If we can communicate effectively, we can fix shared misunderstandings.
00:22:48.800 And ultimately, if miscommunication persists, coding becomes convoluted.
00:22:55.920 Being transparent leads to successful outcomes and fosters healthier environments.
00:23:02.400 You will observe burnout among those always on call, fearing to miss messages.
00:23:09.920 So keeping boundaries clear helps in preserving mental stamina.
00:23:15.840 Most heroes arise from negative organizational environments.
00:23:22.240 Consider the reality: we need to experience pain in order to change.
00:23:30.400 People should confront the discomfort that pushes change.
00:23:37.680 It’s crucial to embrace challenges with foresight.
00:23:43.600 Yet, we risk falling back into old habits.
00:23:51.040 Evaluating our work methods leads to a thoughtful investigation.
00:23:57.920 Ultimately, we excel when we lean into constructive feedback.
00:24:05.440 Reinforcing trust within teams counters misunderstandings.
00:24:13.360 We have the responsibility to create suitable work-life balances.
00:24:20.720 When we effectively manage dynamics, we improve overall productivity.
00:24:27.760 Encouraging team autonomy is essential for a thriving environment.
00:24:34.560 With this insight in mind, let’s encourage dialogue on humane development.
00:24:42.080 This is about fostering healthy environments where people flourish.
00:24:50.080 I believe we can pursue these objectives collaboratively.
00:24:57.120 Thank you all for your time, and if you’re interested, I have stickers.
00:25:04.160 Feel free to come up for a humane development sticker or any other questions.
00:25:11.600 Just remember, our industry thrives when we remember the values of humanity.
Explore all talks recorded at RailsConf 2015
+122