00:00:11.860
All right, I want to thank everybody for coming today and for coming to see me specifically. I hope everyone's RubyConf has been as great as my RubyConf has been.
00:00:18.560
This has been one of the more exciting conferences I've had a chance to be a part of recently. My name is Brian McElaney. I'm the Senior Vice President of Technology at Think Company, a user experience design firm in Philadelphia.
00:00:26.330
We have a lot of business-minded designers, developers, and project managers working on things like design systems, product design, and more. I'm not here to talk about my time at Think Company; most of the stories I'll tell today are about my early days as a development lead.
00:00:37.010
These are decisions that seemed like good choices at the time but didn't work out the way I thought they would.
00:00:43.520
I should mention that I'm going to name one company today; for the rest, I'm trying to obfuscate a bit. However, nothing I'm going to say today should wow anybody. These are things that we all sort of experience.
00:00:49.880
The goal of this talk is to start forming a vocabulary around these matters so we can name them and take back some power over them. I should also ask that you please bear with me; this is kind of a terrifying talk to give because I'm discussing seven of my biggest blowups as a dev lead.
00:01:11.509
When I use words like 'we,' 'us,' or 'they,' keep in mind that I was a key part of all these decisions. I'm not trying to disown any of that.
00:01:18.109
I've had a unique career as a developer, working in many different contexts in the industry. I've worked as a consultant, where people sold my time. I've been in product companies, where people sold the things that I created, and on internal teams—it's kind of like overhead to the workings of the business.
00:01:31.909
I've been involved in wildly overfunded and wildly underfunded projects, in giant enterprise organizations and tiny little nascent startups.
00:01:37.069
Throughout all of that, we found ways to make software go wrong. It seems that none of those factors really matter when it comes to making things succeed.
00:02:00.079
Let me tell you a story about a project that didn't succeed but was one that I learned a lot from. I was working for a motorcycle parts and apparel firm called Rozilla.
00:02:06.229
We merged with another company, and we were trying to figure out how to iron out their e-commerce experience with ours. We realized that their giant enterprise e-commerce platform was just never going to do what we wanted it to do.
00:02:24.480
So, we decided we were going to build a new one from scratch. Furthermore, we decided to do it in a programming language that none of us knew, using a functional programming paradigm, while I was from an object-oriented background.
00:02:31.859
I got sick and ended up in the hospital for several months. When I came back, I coded on painkillers for a while afterward.
00:02:37.829
I was one of the leads on this project, but when another lead quit, everything was kind of stacked against us.
00:02:44.489
We hit deadlines, and during a one-on-one with the CTO, he asked me how I felt about the project. I told him it was horrible—a giant pile of bugs and tech debt that we were calling software. It couldn't be launched.
00:02:57.629
The CTO responded by asking about security problems. I said I wasn't aware of any, and then he asked about performance and memory leaks. I assured him that we were good there.
00:03:09.000
Finally, he said, 'You know what? This is just tech debt. This is how people want software. It's fine—hit the button.' So, I hit the button, launching the largest amount of tech debt I ever knowingly placed into production.
00:03:16.379
Here's the thing: I was both right and wrong. What he saw, and I couldn't, was that if I wanted two more weeks to make this better, that was really what I was asking for. He recognized that the increase in revenue from switching from the old platform to the new one would justify doubling the size of the dev team and spending six months refactoring the software.
00:03:31.909
He was able to see the business impact where I couldn't; I was only focused on tech debt, which can destroy the experience I had on many projects. In the years following this experience, I realized that a 10,000-line method is easy to point out and say this is bad for my codebase, or a big pile of tangled statements is similarly easy to identify.
00:03:51.989
But I don't think they've ever destroyed a project if you define failure as the product never seeing the light of day. However, I have seen projects fail to achieve what they aimed for.
00:04:03.569
What I realized was that not all project failures are due to tech debt—process debt has killed most projects I’ve been involved in that didn’t succeed. Debt works like friction: you don't stop a train by applying a ton of pressure to one wheel; you stop it by putting little bits of pressure on many wheels.
00:04:15.930
Over time, that will grind the behemoth to a halt. So we’re talking about these little things. They might not be dangerous to a project on their own, but if left unmanaged, they have the potential to stop a project from launching.
00:04:28.770
We're discussing this through the lens of the seven deadly sins—not as a religious talk, but as a lens for understanding unproductive behaviors in teams. We'll talk about each of these in turn, with a story that goes with each one.
00:04:43.940
First up is anger. Anger is a strong or hostile reaction to a perceived slight, and the term 'perceived' is important here. These slights don't have to actually be real; we face many pressures on projects, such as budget pressures, time pressures, and prestige pressures.
00:05:01.039
We want our clients, customers, and stakeholders to think we are on top of our game. All these pressures can create friction that eventually grinds us down.
00:05:12.440
Years ago, I was part of a project with a major reinsurance company. We needed a BI tool to evaluate risk over time and had six teams involved: a data cube team, a data science team, two app-tier teams working on various parts of the business logic, my team for front-end and data visualization, and finally, the SharePoint team.
00:05:30.979
We realized we needed to move faster than our collective efforts allowed and decided to work in our corners, agreeing on contracts and APIs in isolation, planning to integrate later. Many of you may have heard the common fallacy that integration would only take three days—so I went away for six months.
00:05:52.960
When I returned, I stepped into the client's office, and within the first hour, three developers from other teams asked me to review their resumes. I knew something was wrong and started looking into it.
00:06:08.060
What I found was a requirement everybody missed: a t-shirt sizing for risk. This required an understanding of various geo-locations, and the concept of t-shirt sizing was never going to work without someone overseeing those requirements.
00:06:20.960
Project went over budget for two years before the client finally killed it and moved on to buy a product that better met their needs.
00:06:30.640
This wasn't a bad call; parallel work can work, but you need someone like a conductor in the orchestra to keep track of everything happening. Without that person, you lose coordination, leading to coordination debt.
00:06:44.270
An object lesson for my team is dragon boating, which is an interesting sport that requires 20 people to paddle in unison. If one person tries to paddle faster than everyone else, the boat slows down.
00:07:02.640
In software, this matters because by the time you realize a developer has done the wrong thing, it's usually too late. The code has already been written, and at best, you get churn, depending on how large the issue is.
00:07:20.300
I love this quote by Seymour Cray: "The trouble with programmers is that they can never tell what a programmer is doing until it's too late." In a way, this is like Schrödinger's scope; any task in a project is infinitely large and small until you actually do it.
00:07:37.730
This is why in agile methodologies, we talk about points instead of hours. Velocity is what matters, not necessarily how long something takes.
00:07:50.920
So how do we get around this? We need to get in sync. We need to share priorities, values, and communication systems. This isn’t about tools like Slack or Confluence; it’s about understanding.
00:08:00.130
I recommend visual feature documentation because it’s easy to misunderstand prose, especially with team members coming from different backgrounds and cultures. Iterative prototypes help too—moving from design to code as quickly as possible, and hopefully placing that code in front of actual users.
00:08:16.700
Having well-documented APIs, as discussed in TV McMinn's talk on awesome APIs, ensures continuity and understanding. North Star design helps keep everyone aligned as you're moving through iterations.
00:08:29.840
Ultimately, it’s about orchestrating a process to raise and lower voices as needed to ensure we get software out the door. One other talk to bring up here is Ivan Venkov's discussion on visualizing object-oriented programming, which focuses on low-level visual documentation.
00:08:46.420
The next deadly sin is desire—a longing for fulfillment. Imposter syndrome is real, and even as I stand on this stage speaking about software development, anxiety can creep in.
00:08:56.700
Desire that isn’t managed, especially on an entire team, can result in significant damage to the business. Some years ago, I was working on an environmental reporting application.
00:09:08.420
Our stakeholders insisted on specific features regarding content governance on the project. After assessing the features, our team concluded that we weren’t sure if it was technically possible.
00:09:23.200
Thus, we reached out to contractors for their insights, and the consensus was similar: it might not be feasible.
00:09:31.230
However, we were determined and buckled down, ultimately putting in approximately 8200 hours of effort and delivering the feature. Ironically, the project never launched—this had nothing to do with our efforts.
00:09:47.000
The message here is that while hard work may seem praiseworthy, it can have detriments. Short, intensive sprints can be gratifying, given buy-in from the team, but they cannot last forever.
00:10:02.960
If your entire team experiences morale debt from overwork, you risk burnout. In the example I provided, we celebrated achieving what was initially considered impossible.
00:10:20.060
The leadership praised our dedication—employees were happy because they'd received a solution they didn’t think was possible. However, the entire team was burnt out, and we exploded every estimate for the next 18 months.
00:10:34.630
Thus, I coined the term 'morale debt': trading emotional safety in the name of delivering results. This might be tolerable during short bursts, but teams with morale debt often feel a conflict between desire and reality.
00:10:47.230
This sentiment of being worn down can stem from other sources too. Ernesto Tagwerker’s talk about 'escaping the tar pit' indicates that projects running over budget or slow shipping contribute heavily to morale debt.
00:11:04.160
Sacrificing quality to escalate tech debt can demoralize a team. Again, none of these issues when taken in isolation are inherently problematic, but combined, they create the potential for burnout.
00:11:16.780
This concept of 'hope creep' becomes prevalent when optimistic estimates aren't grounded in the reality of past experiences.
00:11:27.130
When under pressure, individuals may underestimate timeframes, especially if they lack a clear understanding of project timelines. Thus, planning more granularly is essential.
00:11:43.040
As a rule of thumb, break tickets longer than four hours into half-day tasks. Not only will this track progress, but it also allows for accurate velocity assessments.
00:12:02.420
Pair programming and mob programming helps to get developers out of isolation and counter burnout. Shipping more frequently is vital; nothing boosts morale like hearing users engage with software you created.
00:12:15.130
Furthermore, after intense efforts, the next sprint cannot return to normal; it should be managed to lessen the burden on the team. Leave some buffer days for these refactor actions.
00:12:29.050
Additionally, self-care is crucial for team health. Especially in positions of leadership, one should lead by example by ensuring a healthy work-life balance.
00:12:43.390
This brings us to envy, defined as the pain felt when noticing another's good fortune. Often in tech, developers perceive users as 'others.' This perspective detaches empathy and fosters a detachment from user context.
00:12:59.490
For instance, a large transportation agency aimed to engage a younger demographic but relied on outdated train schedules that required users to adapt instead of facilitating understanding.
00:13:16.960
I once illustrated this point to a stakeholder by highlighting the fact that people often prefer accessible methods of transport rather than wrestling with information overload.
00:13:28.200
The important lesson is: if a project team begins to see user contexts as edge cases rather than essential workflows, they risk creating a product that alienates its audience.
00:13:40.180
This danger can escalate to the extremes where engineers design solutions without considering the user experience, as evidenced by tragedies such as plane crashes due to unfathomable user interfaces.
00:13:57.230
It's imperative to have designers, product owners, and engineers aligned to ensure user contexts are critical considerations in the software's design.
00:14:16.180
Building diverse teams enhances discussions on user experience, leading to more robust solutions. Regular user validation is essential; involving developers in user testing offers insights that help them empathize with user experiences.
00:14:32.130
To conclude, the next deadly sin is gluttony, or overindulgence, particularly as a status symbol. It's not about consuming too much kale; it's about the motivation behind choices.
00:14:47.470
I once observed this dynamic in a logistics service provider where excited engineers misapplied patterns that initially felt cutting edge but ended up creating incompatibilities in a codebase plagued with 300,000+ lines of code.
00:15:06.890
While improvement is vital, it needs alignment and consistency across the codebase to avoid further friction of integration novices trying to piece disparate components.
00:15:22.120
We need processes that keep a continued evolution of good practices; this is where the team must come together to maintain velocity and share knowledge.
00:15:39.400
Lastly, resist the temptation for premature decisions; stack the relevant team members on design choices to gain insights at various levels.
00:15:52.980
Now, let’s discuss greed, which pertains to an insatiable longing for material gain—something required for business survival.
00:16:06.130
During my product consulting experience, one client claimed they lacked the budget necessary for software—yet their flawed processes cost them disproportionately.
00:16:23.420
They were losing revenue by repeatedly sending replacements for defective merchandise without tracking failures, and at once portrayed cost-cutting as a budgetary issue.
00:16:39.850
However, measuring software value cannot solely come down to cost; the value streams attached to each project affect relationships and revenue.
00:16:55.790
Achieving a balance between minimizing costs and maximizing value is essential—often requiring investment in design to optimize the path of product delivery.
00:17:09.990
We encounter a cultural tendency toward politics-oriented development, where misalignment exists in understanding software complexity and timelines.
00:17:27.300
Stakeholder communication around the value of specific development tasks is often nebulous. This underlines the importance of visual documentation to organize efforts based on business value.
00:17:55.160
In pursuing agile methodologies, we should concentrate on the velocity of getting our tasks done effectively, rather than merely completing tasks based on stakeholder perceptions.
00:18:14.250
The last deadly sin involves pride, often inflating an engineer’s perception of their ability and, sometimes, causing negative outcomes in a team.
00:18:44.850
I once worked with a remarkably fast developer, but when tasked with critical updates, they were the only one familiar with the foundational code. Their speed became detrimental to the overall team.
00:19:07.480
As updates happened, this developer lost context, and as new team members joined, they struggled to make heads or tails of what had been coded.
00:19:22.020
Every time they modified structures they deemed fit, everyone else lagged behind and became overwhelmed. This highlights the danger of letting fast developers become torpedoes without direction.
00:19:43.790
This is where the importance of code reviews becomes crucial. Not only do they act as quality control, but they also facilitate knowledge sharing amongst team members.
00:20:05.130
Creating an education-oriented culture can empower teams and deprive the toxic notions of pride from prevailing.
00:20:22.380
Finally, in pursuit of simplicity, I saw a young child replicate their parent's actions in every step toward their daily journey. This demonstrated how valuable it is to create patterns that others can easily follow.
00:20:43.460
Complexity can inhibit velocity and adversely impact development, thereby necessitating practices that promote alignment without excess.
00:21:05.360
Concluding, sloth—defined not simply as inactivity but as a lack of discernment in decision-making—emphasizes the need to exercise caution, plan diligently, and make strategic changes.
00:21:38.490
So, as a summary, consider thoughtful architecture and firm frameworks when executing in development, while simultaneously being attentive to the impacts and connections of team actions to software delivery.
00:22:14.840
I will be around at the reception after the conference and on Slack, so don't hesitate to reach out. Thank you for your time.
