Beard and Bourbon

The test of a first rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function. – F. Scott Fitzgerald

One of the major differentiating factors between a junior team member and a more seasoned team member is the ability to “assume positive intent”. This obviously has its implications in interpersonal relationships and conflict management within teams (which I’ll save for another post), but it also has direct implications in software development.

Throughout the entirety of my career, I’ve dealt with software engineers, and fascinatingly, prejudgement is fairly baked into engineering culture. Have you ever introduced an engineer into a legacy code base? The first reaction is almost always: “This is crap!” Or, put more cynically and verbosely: “This implementation doesn’t follow my own personal instincts for how I would have solved the problem!” And then, fueled by enough beers or a close enough circle of confidants, you may even hear “Whoever wrote that was an idiot.” In fact, there’s even a handy command that programmers use for figuring out who wrote or changed a line of code. No, it’s not something like `git history`, which would nicely imply an answer to the question “how has this code evolved over time?” Instead, it’s `git blame`. As engineers, we’re trained to assign blame to someone who did something, not dig into the original intent.

(And, by the way, this isn’t unique to software engineers. I’ve seen people react the exact same way after ripping drywall out of a house: “Whoever did this electrical work was an idiot!”)

The solution to this is actually fairly simple: we need context. Assuming that the original programmer wasn’t on the nefarious mission to destroy the productivity of any future inheritor of this code, there are almost certainly a set of conditions that facilitated a piece of software being written in a certain way. Perhaps deadlines caused for a rushed implementation; perhaps an outage warranted a strip of duct tape that never quite got cleaned up; perhaps the office coffee machine wasn’t functioning that week; perhaps that piece of code has existed since the CEO wrote it in a 36-hour Redbull-powered coding binge back in his college dorm room.

The engineers I have most enjoyed working with are able to work under these assumptions. As they see more and more historical code throughout their careers, they start to recognize these common afflictions within legacy code, and they bring their other team members along through that journey of understanding and empathy.

As anyone who has worked with me will tell you, I don’t enjoy scrum as an Agile methodology. While the concept of sprints and scrum teams serve their purpose, I find that having flexibility in both deadlines and team composition is an invaluable tool in certain circumstances. Taking the example of a new, large project comprised of months of effort and many milestones: it can be advantageous to have smaller, flexibly-sized teams (which I like to call “Taskforces”) organized around smaller sub-projects or tasks, which can change over the course of the larger project. Using sprints, a project lead is concerned with coming up with a deliverable to fit into a fixed number of days of development. Using scrum teams, a project lead is concerned with sizing these smaller sub-projects to best make use of all team members on a given team. By keeping both the deliverable time and the team composition flexible, the team can better adapt to the changing nature of the project.

Opponents and critics to this approach will point out that the beauty of scrum is that the team can more accurately measure their velocity the longer the same group works together. In theory, this is perfectly valid. In practice though, given the short-term “gig economy” that we work in, that measure becomes less and less accurate (and therefore less and less meaningful). I would offer the counter-argument that by allowing/permitting/encouraging teams to change their composition,  team members will be exposed to more of their peers more often. This exposure will offer new perspectives, increase the chance of getting valuable feedback, and up-level the individuals.

Of course, this does not preclude me from trying to hold other agile ceremonies such as Backlog Grooming and Standups; both are valuable tools to communicate goals and statuses to the team. The only thing that changes is the delegation of the work and to whom.

I was inspired to write this post based on a concept — Management Debt — from Ben Horowitz’s book “The Hard Thing About Hard Things” (http://www.bhorowitz.com/management_debt). If you haven’t read the book, I implore you to stop reading this right now and go get it. Here’s the gist of it though:

Thanks to Ward Cunningham, the metaphor technical debt is now a well-understood concept. While you may be able to borrow time by writing quick and dirty code, you will eventually have to pay it back—with interest. Often this trade-off makes sense, but you will run into serious trouble if you fail to keep the trade-off in the front of your mind. There also exists a less well-understood parallel concept, which I will call management debt.

He lists three main causes of management debt, but I believe there is a fourth major cause that is very common in rapid growth organizations: under-equipped senior individual contributors being placed in management positions. Akin to the Peter Principle, this anti-pattern arises when a high-performing member of the team is given a position of leadership without the necessary training, mentoring, or guidance required to be successful in their new roles. “She’s doing a great job! We should promote her to a manager so that she can do even better things!” Management trainings, mentorship opportunities, and strong 1:1 coaching go a long way towards redefining what success means, acknowledging the fact that individual’s careers are directly affected by their day-to-day decisions, and laying the groundwork for their own personal management philosophy.

To make things even more complicated, the implicit or explicit “seniority” tends to transcend the role change. As the instigator of such a role change, senior management needs to adjust expectations that the new manager will be leaving behind (nay, delegating) certain responsibilities that made him/her very successful in their “senior” role and taking on new responsibilities that will inevitably make him/her feel very junior. Even more importantly, the senior manager will need to convey that this feeling is healthy and that performance expectations will also be adjusted for the new responsibilities. A manager who does not shed the old, albeit comfortable, responsibilities risks becoming overloaded, stagnating other members of the team who wish to grow, and earning the label of a micromanager.

All of this is to say: if you are the one making the decision to transition one of your leaders into a management role, you are accepting the responsibility of teaching empathy, dependence, and humility. And if you are the one transitioning into a manager, be mindful not to conflate this move with a promotion. In the eyes of the organization, you may have just moved up the ladder, but you must now acknowledge that you are the new kid on the block again.

I’ll do my best to keep up with a post every week, but as of now, I have no idea where the majority of my inspiration will come from on an ongoing basis. What I can say is that, as much as I try to avoid it, work maintains a taxing presence on the problem-solving center of my brain inside and outside of business hours; you’re very likely to see my writing veer that direction occasionally. What I’d like to make sure is an ongoing theme is the other non-employment-related aspects of my life, such as woodworking, motorcycle riding, music, and family life. That’s the beauty of the domain beardandbourbon.com (the brainchild of my lovely and brilliant wife): it’s so perfectly alliteratively subject-agnostic that this blog can turn into pretty much anything.

A couple years ago, in a H. O. G. magazine, I saw an intriguing journaling idea that seemed to have a low barrier to entry and minimal time investment. The idea was that you would keep a notebook on the motorcycle, and every time it rolled over 1,000 miles, that was your cue to write a small entry about where you are, what you are doing, and possibly something more introspective like what is on your mind. So, I started doing this on my road trip from San Jose, CA to Ocean City, MD, and it worked decently over those 8,000 miles. Unfortunately, it all fell apart once the majority of my riding became commuting to and from work; apparently I pay closer attention to the odometer when riding is the focal point of 10+ hours of the day.

So, I have repurposed that leather-bound notebook (seems like a waste to just have it sitting there) into a sketch book. Now, mind you, I can’t draw. Never have been able to. Never even really had a desire to. But my wife and I recently took a road trip around the east coast (on four wheels, sadly), and she started sketching different things that caught her eye. Architecture, bridges, landscapes, signs, whatever. And guess what? It’s awesome, and it made me realize that she’s infinitely more talented than I am. Seeing her get so much satisfaction from having a pictorial account of our trip tells me that I’m probably missing out on something. So, I’ll try my hand at sketching too. Who knows? Maybe you’ll be unlucky enough to see one of those when I stop being self-conscious about drawing.

So, that’s pretty much all for now. I’ll work on the next edition over the course of this week.