Too Much Software Development, Not Enough Professional Development

I’ve been reading a very interesting book written by John Bogle of Vanguard fame called “Enough”. It’s a wonderful read and highlights some very fundamental values he espouses and has lived throughout his life. You can get a feel for the book simply by looking at chapter titles. Here are chapters 1-3:

  • Too Much Cost, Not Enough Value
  • Too Much Speculation, Not Enough Investment
  • Too Much Complexity, Not Enough Simplicity

One chapter in particular, “Too Much Business Conduct, Not Enough Professional Conduct”, struck a cord with me in a number of ways. It reminded me of Bob Martin’s Craftsmanship and Ethics outlook and books espousing a professional code of conduct.

In Mr. Bogle’s book, he discusses an article that describes 6 core principles of a profession, a professional, and professionalism.

6 core principles of a profession:

  1. A commitment to the interest of clients in particular and the welfare of society in general
  2. A body of theory or special knowledge
  3. A specialized set of professional skills, practices, and performances unique to the profession
  4. The developed capacity to render judgments with integrity under conditions of ethical uncertainty
  5. An organized approach to learning from experience, both individually and collectively, and thus of growing new knowledge from the context of practice
  6. The development of a professional community responsible for the oversight and monitoring of quality in both practice and professional educators.

“The primary feature of any profession is to serve responsibly, selflessly and wisely and to establish an inherently ethical relationship between the professional and the general society”

As I read the list, I tried to think through MY chosen profession and wondered if we consistently have “Too Much Software Development, and Not Enough Professional Development”. I also wonder how many of the above 6 principles my community exhibits. Sadly, it seems very few. What’s interesting about that is how awkward it is to think about true professions behaving like we tend to behave in our daily work.

Some examples of professional absurdity from 2 well known professions (Medicine and Law):

  • Think about the lowly hand surgeon. You go into their office with a little hand pain. If your hand surgeon tells you that you don’t need surgery, do you force them to do surgery anyway? On the spot? Moreover, would a professional hand surgeon actually do it because they notice that you seem upset?
  • Now think about a lawyer. You get caught stealing Ryan Braun jerseys from the local truck stop. You stop in to see your lawyer and tell him about the case. Do you tell the lawyer you won’t use him unless he guarantees, unequivocally, that you will be acquitted of all charges? Would a professional lawyer tell you they know, without question, the outcome of your case? What if you were wealthy, intelligent, wore a suit to the appointment, and seemed upset? Would they guarantee it under these circumstances?

Each one of these 6 principles could generate its own post, but I want to focus on the quote above from the book. I key in on the words “serve responsibly, selflessly, and wisely” and it conjures memories of all the discussions I’ve had, witnessed, or lead that were simply attempts to cajole development staff (myself, peers, direct reports) to leave their professional judgment at the door. I’ve written a bit about why this happens, and the fact that there are no villains in this equation. Everyone is operating with the best intentions.

Knowing there’s rarely something subversive going on, I think our community members need to think much harder about their professional conduct as much as the next great framework or development practice. As a trustee and steward of technology, our obligation to the “greater good” is to stand up and help others make good choices.

“Develop a capacity to render judgments with integrity under conditions of ethical uncertainty”.

While we may not face unethical choices, we clearly face choices of uncertainty. In this regard, the work Bob Martin is doing is wonderful. That said, the “6 principles of professional conduct” message tends to get muddled by the 1 or 2 principles espousing the, mainly, technical skills development and practices.

For now, I leave you with one question. What are you doing to teach and advance the profession of software development, in its entirety, in your organizations?

 

Cut Us Some Slack! (and why that helps both of us)

I decided to write a bit on slack based on my all-to-regular defense of slack in my daily work.

Most employers and managers tend to erroneously equate Activity with Value.

“If we keep people busy, we will get more done” is a common refrain and seemingly fundamental belief. Leaders tend to put more energy into increasing current capacity than the more powerful approach of understanding throughput. This all happens for good, although misguided reasons. Allowing the appearance of “wasted bandwidth” in your system is more than uncomfortable – it feels criminal. Especially in systems that are struggling and overburdened.

There is so much to do! We need to get every drop of available capacity from our teams we can! NO DOWNTIME!

Paradoxically, these are the times we as leaders should lead and teach our teams that slack is not only appropriate, it’s likely the only way to get out of the mess we’re in. I know what you’re thinking. But how could that be?! We’re behind and you’re telling me to allow, nay force people to be less than 100% allocated!?

….yep. And here’s why.

Metered OnRamps

If you think about the (overused by me) analogy of a highway, why is it that we don’t crank the system to 100% of its capacity, filling every available slot on the road with a vehicle? It seems pretty simple in these terms. It’s because our highway would quickly become a parking lot. However, our expectation is that a completely full highway moving at 65 mph yields the best throughput over time. This sentiment is unequivocally true. No doubt about it.

So why does the highway operate so inefficiently at 100% capacity? The reason is that each “seemingly independent” vehicle on the road depends on other vehicles on the road to get to where it’s going. If one of these inter-dependent vehicles brakes suddenly, the cars behind it have no option but to do the same. The result is a tsunami of brake lights and the system slows dramatically. The cars on the road have no ability to absorb even minor changes to the system, and therefore the entire system is affected by minor changes (I assume you’ve heard of “gapers delay”?) Throughput in a system like this is completely constrained by minor issues and ultimately you get wild fluctuations. From very high throughput to near zero.

To achieve the absolute highest levels of throughput in a real world system, the trick is to work and experiment your way to the inflection point where:

  1. too much slack artificially degrades throughput (meaning we are missing an opportunity to add more vehicles without degradation of the system) and
  2. too little slack that ensures any minor (and inevitable) system changes become amplified and choke throughput.

The World of Teams and Portfolios

There’s nothing trivial about building slack into your systems, or daily lives for that matter. What is clear to me is how critical it is. My advice to you as leaders is to “keep your eye on the baton, not the runners” (Vodde, Larman). Work to largely ignore “activity” and focus ALL of your time trying to understand the total throughput in your system. Make small changes to your systems and portfolios and observe the impact.

Slowly filter “work” into your system and observe the point where more work yields less delivery. When that starts to happen, don’t panic and spin up more projects to fill peoples time. Relax. Breathe deep and look around your system for the next challenge. I promise you’ll find some.

A Model for Effective Tactical Meetings (for Leaders)

One of the keys to successfully leading teams of people is to run effective meetings. On the surface, this seems pretty straight-forward. Ensuring you have an agenda, take good meeting notes, and sending action items out afterword aren’t rocket science. Relatively trivial, even though consistency is key and rarely is delivered. However, when you are dealing with those recurring tactical meetings, especially ones that occur multiple times per week, the old model falls down.

To begin with, there really isn’t a simple strategy to produce detailed agendas any longer. Many topics, the critical ones that need to be discussed ASAP, sometimes come up just hours before the meeting. Furthermore, the priority of the litany of things that are on the list changes at a rapid pace. Sending anything in or prepping for those discussions can be fruitless at best, and counter-productive at worst.

Enter the “Weekly Tactical” meeting format:
Some of the concepts in this format were adapted from the book, “Death by Meeting” by Patrick Lencioni, but others were evolved on the spot as the need arose.

The basic premise of the Weekly Tactical meeting is to get a group of leaders together to make decisions. We don’t want to go to meetings to “talk” about decisions, we want to MAKE them. (After all, that’s one of our core job functions) So many organizations are plagued by the notion that meetings are simply to “discuss”, not to “do”. This simple shift alone will increase the effectiveness of most meetings. The word Tactical, for our team, implies that the scope of topics should cover 1 week from the date of the meeting. We have 2 Tactical meetings per week that are 1 hour each.

Detailed Overview:
The following photos show the simplicity of the process. I have a large whiteboard in my office that is refreshed each time we have this meeting. It has the template written on it and is ready when the team comes in. The image at the right shows what the layout looks like. I tend to facilitate the sessions, but now anyone can do it as the process is simple and well understood.

Next let’s break down each section with details.

Lightning Round:

Decencies
We have recently added a kick-off titled “Decencies”. This is probably the one I’m most excited about, and most proud of. After re-reading Tom Peters book, “The Little Big Things” last week, I was reminded of the need to refocus our efforts on our people. I’m leading a group of manages and architects and we tend to get mired in the day to day. The complexity and pressure for those leaders is immense and it’s easy to get stuck focusing on “work stuff” and neglecting the “people stuff”. Tom reminded me a second time “it’s all about the people”. Hence, the “Decencies” kickoff was born.

Essentially we will create actions to recognize the wonderful and talented staff we have and the things they do every day to make all of us successful. We will also think about ways to remember the Power of Pleasant, how we can connect emotionally with our customers, and hopefully keep some “damned perspective” when the tension escalates.

Topics
We then go to each person and ask for their topics. If you have an issue or topic that you need help delivering, or you need a team decision, then it’s a good topic for our meeting. They each have 1 minute (yes, 1 minute) to get through their entire list, along with associated explanations if needed. We then move to the next person, in order, until we have a list of topics. We then get started at the top of the list.

Note: we used to prioritize the list, but as of late, we have blown through very large lists so rapidly that we haven’t needed to prioritize. If we start leaving important stuff undone, we will go back to prioritizing.

Actions and Decisions:

We then take each topic one at a time and attempt to give each topic its due attention. We are all aware of the need to get to an Action or Decision so we tend not to lollygag. We will discuss for a while and someone will say, “Do you need us to help choose for you?” or “Is there a next action for this that we can assign to one of us?” More often than not, the topic simply needed a quick decision and some collaborators to ensure there wasn’t something being missed. Other times, the issue is a bit more complex and the initiator needed help deciding on the next steps to take.

As we move through the list, the grid in the image to the right begins to unfold. We assign tasks with associated details, 1 per line until we’re done. Normally a “decision” is indicated with a task to communicate the decision so we ensure we are communicating those decisions effectively.

Parking Lot:

As a group, we occaisionally bump into a topic that has no simple solution or the right parties aren’t present to discuss. They also span many teams and possibly a large time horizon. These issues we deem “strategic” and get placed in the parking lot with associated detail. We have a few venues that these strategic topics can end up in so we attempt to classify them on the spot

Note: this classification exercise is new. I will update you on how its going.

The three Strategic Meetings are a “TRI-Weekly” meeting that we prepare for in advance. It includes both leadership teams in my organization (Development Managers and Enterprise Architecture) as well as any special guests needed to (once again) make decisions on the topic at hand in the meeting. The second is a “Development Manager” Strategic meeting and the third is “Architecture” strategic meeting….all similar formats. I will try and describe these formats in a subsequent post.

 

Well, there you have it. This evolved format has helped our team and organization communicate better, make timely decisions, and get aftet the topics we know are critical for success. With the addition of our Decencies section, it will also help us double down our efforts to remain focused on whats important, our people and their well-being!