Sharing Lunch

My name is Jim Kimball. I am CTO at HedgeServ, a Hedge Fund Administrator in New York City. My goal is to facilitate an environment that people want to work in. This blog is a place for me to clarify thoughts and ideas and hopefully engage in discussion with other people who think about technology and organizations. I appreciate comments.
Recent Tweets @jimkimball

The Extract Method refactoring starts on page 110 and runs through page 116 of Martin Fowler’s seminal book “Refactoring (Improving the Design of Existing Code)”. He describes 9 steps to use when executing this particular refactoring.

  1. Create a new method, and name if after the intention of the method (name it by what it does, not by how it does it)
     -> If the code you want to extract is very simple, such as a single message or function call, you should extract it if the name of the new method will reveal the intention of the code in a better way. If you can’t come up with a more meaningful name, don’t extract the code.
  2. Copy the extracted code from the source method into the new target method.
  3. Scan the extracted code for references to any variables that are local in scope to the source method. These are local variables and parameters to the method.
  4. See whether any temporary variables are used only within this extracted code. If so, declare them in the target method as temporary variables.
  5. Look to see whether any of these local-scope variables are modified by the extracted code. If one variable is modified, see whether you can treat the extracted code as a query and assign the result to the variable concerned. If this is awkward, or if there is more than one such variable, you can’t extract the method as it stands. You may need to use Split Temporary Variable (128) and try again. You can eliminate temporary variables with Replace Temp with Query (120) (see the discussion and examples).
  6. Pass into the target method as parameters local-scope variables that are read from the extracted code.
  7. Compile when you have dealt with all the locally-scoped variables.
  8. Replace the extracted code in the source method with a call to the target method.
    -> If you have moved any temporary variables over to the target method, look to see whether they were declared outside of the extracted code. If so, you can remove the declaration.
  9. Compile and test.
I realize most modern IDEs have refactorings built in. I like developers to understand the details of the refactoring. It is part of the fundamentals of programming. It is not uncommon for programmers to scoff at the detail Fowler goes into for something “as simple” as cutting and pasting code. The fact that it takes Fowler six pages to properly describe this refactoring speaks to the complexity of technology. Everything matters. A mistake made in this refactoring contributes to the degradation of a code base. That degradation is the difference between code that evolves and code that collapses under its own weight.

Our organization is in the process of reviewing our technology processes to improve our capabilities and provide a higher service level for our business. We have been automating more of our infrastructure for better quality and repeatability. Even with our newfound technical capability, we struggled to achieve consistency in our server builds without requiring late nights and weekends from our technology team. Through our partnership with Praxisflow, we got to spend some time with Paul Reed, aka @SoberBuildEng. Paul spent a couple days observing our process and then suggested that we were missing proper documentation of the steps needed to execute our tools - i.e. a checklist. The notion that we needed to document steps to run our “automation” struck many in our team as counter to our mission and there was some initial push-back. But the team worked through it and built a checklist to execute our system build. When they were done, they had 39 steps in our build process! It was sobering.

I was privileged to sit with a pair who were executing the checklist recently and, as the team was executing the checklist, the parallel to pair programming and the way the two people help each other maintain the discipline of refactorings like the one above hit me. The process of executing the checklist is just as important as the checklist itself. There is an executor and a validator. Each person actively participates by executing steps independently as a means of validating the entire process. The coolest part was the communication. When a pair of programmers are “in the zone”, observing the communication is like watching a great sports team - people know where their partner is going to be and lead them with the next question or bit of feedback. I saw the same thing with the checklist execution. The two people involved got into a steady buzz of back-and-forth communication. While I was watching, the team identified multiple areas where their checks caught a problem that may or may not have caused an immediate client issue. But it would definitely have contributed to the degradation of our infrastructure. And we don’t want an infrastructure that collapses into endless unplanned work - we want an infrastructure that evolves.

Much like IDEs handle the details of the refactoring, we will enhance our tools to minimize the steps involved. But it is comforting to know the team understands those steps and knows how to execute whatever steps we need with precision. 

We had an outage today. I hate outages.

Outages are the worst form of unplanned work. It requires the response team to correct the situation, then the appropriate people need to analyze how it happened, and the whole time users are anxious to know what is going on, and business owners are upset and want to know what happened. It is extremely stressful to all involved.
This particular outage happened this way.
We use a third party application that must be recycled every night (yes, it does). So we have a job that runs on a schedule to kill all client sessions across all Citrix servers. A scheduler is used to manage all production jobs and it has a configuration setting for the maximum number of jobs that can run at a given time. We do regular maintenance on the scheduler to purge old data. This maintenance requires a bounce of the scheduler application server. When we bounce the scheduler application server, we first reset the max job queue to 0 so we can prevent any new jobs from starting, then we restart the app server and reset the max queue to its proper setting.
The reset of the max queue setting does not have any error handling.
So, can you guess what happened? The reset of the max queue setting failed, meaning the max queue setting stayed at 0, meaning the scheduler did not run any jobs, meaning the bounce job didn’t run. Morning checks noticed that the applications were bounced and so the morning team bounced the app manually. Later in the morning, someone noticed that the max queue setting was still 0 and so set it to the correct value. Then the kill_client_sessions job ran, killing all client sessions. In the middle of the day.
I hate outages.
Especially self-inflicted outages.
This script in question was written 5 years ago and has never failed. Until now. The fact that a script doesn’t check errors is hard to know when the script has been running successfully for 5 years. Good coding practices are there to prevent this exact thing from happening. You always check errors. You always write output to a log file. This is what DevOps/OpsDev means to me. And I am excited that part of our breaking down the walls between dev and IT has resulted in strong coding practices for our operations scripts.
 
But I ignored the fact that we have many scripts built before these practices were put into place. Any one of them were waiting to bite us and this one did. So now we are reviewing all production scripts to make sure they provide us the best level of protection we can get.
I hate outages.

Over the years that I have been CTO at HedgeServ, members of our technology group have given me feedback many times about the need for “better communication”. My many early attempts to address this concern were to have status meetings with large groups of people to talk about what they were all doing. I sent email after email describing the details of what was going on. If they wanted communication, dammit, I would give it to them. But the people working in our organization weren’t satisfied, and I wasn’t either.

Clarity Trumps Detail

Having more meetings and sending more emails was my attempt at addressing concern about communication by providing details about what everyone was working on. It turned out that, while these details may or may not have been interesting to some people, it didn’t satisfy the need people had to understand how their work fit in with what we are trying to do in the business.

From The Art of Action: Leadership that Closes the Gaps between Plans, Actions and Results

Providing more detail is a natural response to a demand for clarity. But clarity and detail are not the same thing at all. The pursuit of detail actually increases noise and so makes it less clear what really matters. Details change quickly, so the more details we put in our plans the less robust they will be. Opportunities are missed, and by the time a decision has been made, the situation has changed, prompting further information gathering and analysis. The more detailed we make action plans, the more we constrain what people can do, which increases rigidity. People become demotivated and keep their attention firmly fixed on their KPIs, which become more important than what they were supposed to measure. Commitment is replaced by compliance, energy is sapped, and morale declines. The end result is a slow, expensive robot.


So if providing more details is not the right way to respond to the need for better communication, then what is? What is this clarity that you speak of? We provide clarity by answering some basic questions:

  1. Why do we need to do this project?
    We tell people why this project is important. How does doing this project help the business to achieve its goals? In talking about why the project is important, it forces us to explain the current state of the business. Where are we strong against our competitors? Where are we weak?
  2. What are some initial steps we are going to take to execute this project?
    We can’t dictate every step because our goals involve exploration and experimentation, and we don’t know what we will find along the way. But we will point out some initial steps to give some context to understand what we mean and to help people get started.
  3. How will we know if we are succeeding or failing?
    Leaders in the organization have always had their own heuristics for monitoring how a particular project or exercise is going. It might be the way people communicate in meetings. It might be the amount of time it takes to release software, or the number of bugs reported. It might be the stress levels approaching a release. It might be the number of hops an email thread makes before a decision is made. Clarity comes from making these heuristics visible to everyone. For example, if you want small experiments to learn information, you might say, “I will know we are failing if I see a lot of people in long meetings” or “I will know we are failing if I don’t have people coming to me saying we are lacking a given expertise”.


As a leader in the organization, I have been amazed at the abilities opened up by the information contained in answers to the questions above. We don’t need lots of meetings for people to solve problems! And I don’t need to personally participate in those meetings to make sure we “stay on track”! People are able to take an intent and make it their own - exploring it, asking their own questions, doing some experiments, evaluating results and determining next steps. And by already have thought out (and communicated) success or failure heuristics, when we do need to meet on something, we have a shared context that helps make the meetings we do have more productive.

Side Effects

One heuristic I use to know if our changes are appropriate is when the side effects that inevitably arise from change provide positive reinforcement in other ways.

By focusing on clarity, we create simpler intents, which gives us a better chance at achieving them. Art of Action also says What is not simple cannot be made clear. If we have difficulty answering our three questions, then maybe we need to revisit our intent - if we can’t say why we are doing it or how we will know if we’ve succeeded, then how can we expect a team to deliver against this intent?

Attempting to provide all of the details also discourages learning and experimentation. From Taiichi Ohnos Workplace ManagementIf insufficient details are provided, then some managers will say, ‘That’s too high level. Give me more specifics.’ However, the specifics are what managers must learn…By focusing on clarity instead of details, we create an atmosphere that requires experimentation and learning. You have to figure the details out for yourself! As a result, our whole organization benefits from the full participation of our people instead of getting “slow, expensive robot(s)”.

We still have a lot to learn, but now I feel like we have the entire organization learning together, which feels good.

Here at HedgeServ, we have grown pretty rapidly and our technical infrastructure has been growing rapidly at the same time. Many months ago, our technology leaders got together and talked about how we can put ourselves in the best position to continue our growth. In that meeting we talked about DevOps and how DevOps principles might help us. We agreed to begin adoption of some of those principles.

This post is not intended to describe what DevOps “is”. I think of the word “DevOps” like “Agile”. It represents a notion that we should think about *why* we are doing what we are doing and to re-evaluate if what we are doing is the right thing. Here are a couple resources that have helped shape my thinking on the topic: here (money quote from @jeffsussna in the comments, “The ability to tip up 100 Apache servers at the push of a button doesn’t necessarily address the relationship between Dev and Ops”), and here.

We have over 200,000 lines of PowerShell code that we use to automate our infrastructure. This code was written by the individuals on our IT team who took it upon themselves to learn PowerShell and use it to solve their problems. I am amazed by what they have accomplished pretty much on their own. With our shift to DevOps thinking, we have started having design discussions with both Ops and Dev in the room for tasks that were traditionally Ops. It was in a recent one of those meetings that I learned a few lessons about things I had done as a leader to make things more difficult for our teams, and things I could do differently to give our teams more flexibility to solve problems in the future.

We are a Windows shop. Ten years ago, I counted myself as one of those people who said, “If you are on Windows, you have already lost” (“a venture capitalist…[would] have a hard time hiring anyone good to work for him if the project had to be built on [Windows] NT” - http://paulgraham.com/gh.html). But our platform relied on software that runs on only Windows so we had to make it work. And we did. And I now believe more than ever that a successful platform relies much more on the people building it than the specific technology being used.

The task at hand was the implementation of a new server build to enable a more optimal release process. The team has been building the application (formerly known as “scripts”) and we needed to build some test servers to validate some of the riskiest assumptions. The lead on the project, let’s call him Brent (just came into my head), was saying that the application isn’t done yet but they can use the pieces to create these servers. When pressed, Brent said he would manually execute steps where the application doesn’t work.

Brent was approaching his goal as getting our systems to the point where we had two additional servers! The application he was using to do it was secondary! Lesson #1.

Thanks to our collaboration with PraxisFlow (@kevinbehr, @jabe_bloom, and @john_dennin), we have learned that people who consistently have work forced upon them learn to accept that as the state of the world. They become used to a world full of constraints and therefore have difficulty imagining anything else. Brent was so used to having a large queue of high priority tasks that he could not help but to focus on satisfying the immediate “customer” and deliver his two servers. Lesson #2.

Developers approach problems almost exactly the opposite way. When faced with a problem, they like to try to find a solution that expands their own knowledge, to the point where sometimes the non-developers around them get extremely frustrated. I am reminded of a friend of mine from many years ago. I recall sitting with him while he pulled some data into Excel and needed to get the product of a column of numbers. Instead of copying and pasting a formula that iteratively multiplied the numbers, he thought about it a little and came up with the idea of summing the logs of each number, then using the exponent function to achieve the result. A non-developer next to him complained that he could have gotten the answer much more quickly through brute force, but who knows when that one small piece of knowledge might come in handy again when there isn’t a simple option?

I suggested that Brent use this server build as an opportunity to finish the app. If something breaks, he should delete the server he was in the process of creating, then start over from the beginning. This way, when he is done and the build is good, he knows he has an application he can use to re-run the build again. Brent expressed concern that this approach would slow him down tremendously because it takes two hours to run the build. Hmmmm, two hours? No wonder you don’t want to start over from the beginning. Five iterations of tests and you are at a 10 hour day! Without the ability to iterate quickly, you are going to be resistant to any approach that suggest you start over. Developers have powerful workstations for this exact reason. This enables them to iterate at a very fast rate. I realized that we had never put together a development environment for our IT people. We had created a system that actually discouraged them from learning! Lesson #3

I believe that part of the DevOps way of thinking is to enable everyone in the organization to keep learning at their job. This means eliminating the constraints that prevent people from iterating rapidly. This means giving IT people development training so they learn how to leverage iterations to start small and let an application unfold in front of them.


So the meeting, which started as a discussion about testing specific risks in the build, uncovered how the system that our IT team worked in limited our own ability to grow.

My youngest son is 13 years old and plays in our town’s basketball league with other kids his age. A couple weeks ago, while waiting for his game, I got to watch the end of the previous game.

The game was close, but one of the boys on the team with the lead was clearly the best player on the court. As the game was reaching the end, this boy was simply dribbling around waiting for the time to expire so his team would win. The coach on the other team was frantic, watching the game slip away. He started screaming hysterically at his players, ”Someone guard him!”, making quite a spectacle.

The kids certainly noticed their coaches histrionics and all looked over at him. In response they began running around frantically in no particular direction. But despite all the movement no one actually made the effort to stop the boy who was running out the clock. The time expired and the game was over.

It reminded me of how, in a crisis, people (management?) can make a lot of noise about the problem, saying we need to “put our best people on it” and how we need to make sure it “never happens again”. But in my experience that kind of approach frequently leads to mis-directed efforts. People start taking actions simply to respond to the noise. This kind of response is manifested in dialog of the form “we have to do this or else so and so is going to start yelling again” instead of “we have to do this because it addresses a fundamental problem we have”.

Crises can happen. How do you manage them in your organization? Does management just yell for “Someone (to) guard him!”? 

This article is about an accidental discovery of a self-organizing team right under my nose. It involves my son and his classmates. In the commentary below, I changed some of the details just in case the school doesn’t approve of the approach the kids are taking. The school my son attends is pretty progressive, and in the right context I want to approach the school administration to see what they think. But not right now. I have done my best to keep the substance the same. Anywhere a detail is completely screwed up is entirely my fault. I have included some screen shots of chats, but they are pretty scattered. When I asked for them, I was told that kids delete chat history very aggressively. Apparently kids say things in chat they don’t want their parents to see. I left the original language in. Sorry if anyone is offended. And finally, the extent to which I have made my son sound more like a 45 year-old than 16 year-old is also my fault.

My son was studying for a test at the kitchen table while we were getting ready for dinner. He was using a document on his laptop, which wasn’t normal. Traditionally he had written material he used. When I asked what he was doing, he said it was Google Docs.

It started innocently enough. (D = Dad, S = Son)

D: “What is that material you are studying?”

S: “It is Google Docs”

D: “When did you start using Google Docs to study?”

S: “A couple months ago. A couple of us started using it”

D: “What do you mean, a couple of you?”

S: “Dad, it’s Google Docs. People can share it”

D: “How do you guys share it”

S: “We all take notes into the same document so we make sure we get everything”

Now I am interested. I put down the dishes and sit down.

D: “Wait a second, you take notes into the same document? How does that work? When do you do this? How did it get started?”

S: “Ummmm”

D: “Ok. Maybe you can describe how you guys use Google Docs to take notes”

S: “Well, at the beginning of each chapter in the book is a series of key items and questions that we are supposed to get out of that chapter. So one of the kids creates a Google Doc with those items and questions in it. Then, during class…”

D: “Wait, you do this *during class*?”

S: “Yeah, we all have laptops with our Facebook Group and the Google Doc open”

D: “Wait, where does Facebook come in?”

S: “Well, at the beginning of the year, one of the kids in class created a Facebook Group and sent us all invites. We use it to talk about what is going on in class, ask about homework or help each other with upcoming tests.”

D: “Ok, but how do you use the FB Group in class?”

S: “We primarily use the chat feature in case someone has a question or comment.”

D: “So you have the FB Group and Google Doc open. How does it work?”

S: “We each take responsibility for certain items and/or questions. The person responsible for a particular item edits the doc during class to define the item or answer the question.”

D: “How do address the difference in abilities of different kids? What if one kid isn’t very good at taking notes?”

S: “People can comment on the notes a person is taking. It happens sometimes. Everyone has a color so you know who did what.”

D: “Do kids resent having to support kids who don’t take good notes.”

S: “Not that I know of. We have settled on the rule that, if you don’t think something is right, you write ‘(I don’t think this is right)’ and we figure it out.”

D: “What about the kids who take the notes that get comments? Do they feel bad or like they aren’t contributing?”

S: “Not that I know of.”

D: “Has there ever been a time when someone might go a little too far? Like make a comment on a note that is mean?”

S: “Not really. Early on one kid edited other people’s notes a lot. A couple of us posted on FB that he needed to chill and he stopped.”

D: “How did this get started?”

S: “One kid has been using Google Docs since the beginning of the year to take notes in class. A couple other kids asked him for help one time and he gave them his doc. One of those kids posted the doc on the FB Group in response to a question from someone else. When we got to the next chapter, the kid who created the doc posted the empty doc on the FB Group in advance. A couple of us in class just started taking notes right in it. As they were working, they noticed other kids in the class logged into the doc. One of us posted on the FB Group that we should all just edit it together. So we did.”

image

D: “Wow, how did you manage who was going to do what?”

S: “At first it was a mess. Everyone was just editing the same thing so people were all typing the same thing. On the FB Group, someone posted that we should take turns and each work on something different. We all generally sit in the same place around the table, so we used our seat locations to identify which items we were responsible for”

image

D: “Did everyone know how to use Google Docs?”

S: “It is pretty easy, so yeah”

D: “When did you start using this approach for notes? How is it working?”

S: “A couple months ago. We’ve had two tests since then. I got a B- on my last test before we were doing this. In the test we just had a got a B+”

Who is the manager of this team? Is it the teacher? The school?

Esther Derby has said (http://www.estherderby.com/2011/07/misconceptions-about-self-organizing-teams-2.html) that self-organizing teams require managers to “create the conditions that enable teams to thrive and continue to self-organize”. 

The structure the school provides gives them boundaries for their work - regular times, periodic tests for review, the school network for connectivity, and the requirement that each student have a laptop.

The tests provide them feedback on how they are doing.

Mike Cohn says (http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team) “self-organizing teams are not free from management control.” This is certainly true of the students. They have to be in class on time. They don’t get to pick what time they have class (although what if they could?). They don’t get to choose their tests or other homework assignments. In the same blog, Mike points out that management chooses the product to build. I will stretch that to say that management chooses the goal and in this case, the goal is to learn the subject matter.

For my son and his classmates, they have mostly been together for three years so the team has had time to gel.

Not only am I impressed by the students’ abilities to very quickly take this approach from concept to implementation, but I am also impressed by the way these kids leveraged their tools to create a better way to accomplish their goals. I have recently read articles about “Millenials” and their impact on the workplace. (For example, http://paul4innovating.com/2013/01/25/millennials-see-innovation-differently-from-todays-leaders/). My experience with my son confirms for me that they can be real sources of innovation if we can give them an opportunity.

Correction on Feb 3, 2013: I originally referred to Esther Derby as “ED”. I apologize to Esther and have since changed to list her full name.

We recently began a new project at work. The team decided at the beginning of the project that they wanted to use the opportunity to learn new techniques. I would like to share a recent example that demonstrates two of them.

The first is the difference between Dialogue and Discussion. I was first introduced to this distinction from Peter Senge’s The Fifth Discipline: The Art & Practice of The Learning Organization. Per Senge:

The discipline of team learning involves mastering the practices of dialogue and discussion, the two distinct ways that teams converse. In dialogue, there is the free and creative exploration of complex and subtle issues, a deep “listening” to one another and suspending of one’s own views. By contrast, in discussion different views are presented and defended and there is a search for the best view to support decisions that must be made at this time. Dialogue and discussion and potentially complementary, but most teams lack the ability to distinguish between the two and to move consciously between them.

I learned the second technique we are using from Gerry Weinberg in The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully. Gerry introduces the notion of “The Rule of Three”. According to Gerry:

If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking.

When I use this rule, I think of it as:

If you can think of only two things, you haven’t really thought that hard.

It is easy to know when to apply the Rule of Three. Almost invariably in the course of a discussion, someone will say, “we have two options…”. When everyone on the team knows the Rule of Three, a comment like that is met with a call for other options.

The following example shows how the team used these two techniques to help them solve a thorny problem.

Many financial systems have an “Instrument” class. This class has the potential to be involved in quite a bit of the system’s functionality and, without care and attention it could get bloated and overwhelming. Over the last couple of years as we have been adding new services, this has happened to us. The class grew to over 2100 lines long, it directly imported over 30 other classes, and it had over 100 instance variables directly named in addition to supporting unnamed and uncounted variable arguments. In order for developers to work around this behemoth, they started creating separate, independent classes like “LightWeightInstrument” and “TradeCaptureInstrument”, further confusing the functionality related to Instrument. The team needed to leverage the Instrument class in their project and they decided they couldn’t use it the way it was.

The team set aside time for everyone to participate in a discussion on the design. One of the concerns they discussed was how best to handle those situations where the code needed to call out to an external resource for information. The current implementation used a combination of LazyLoading with caching to direct lookups whenever the resource was needed. As they dove into the concept of lazy loading, one of the team members felt like he suffered when working with a class that lazily loaded values. He worked on an application that had a high performance requirement and he couldn’t provide a predictable experience for his users. Someone else suggested that lazy loading is required to enable someone who doesn’t all of the possible values the class supports. The fact that the team understood they were having a design discussionhelped them to respond to challenges in a productive way instead of taking things personally.

At one point in the design discussion, someone said, “There are two ways we can do this”. The team immediately all set about trying to identify alternatives. In the course of the follow-up, one of the team members referenced the Interface Segregation Principle from Uncle Bob’s Clean Coder videos. He mentioned how, in the ATM example, Uncle Bob pointed out how you can wrap the interfaces of many independent but related classes together into one master interface for users. This strategy allowed the team to support discrete, “eagerly loaded” instances of a detailed class if they desire, while also supporting a higher level generic interface that will lazily load instances as they are needed. The team began digging into this idea and all agreed it addressed their needs.

The final solution the team agreed on would not have been found were it not for their understanding of Senge’s “Discussion”, Weinberg’s “Rule of Three”, and of course Uncle Bob’s Clean Coder videos.

I frequently send articles to members of my firm’s development and management teams that I feel are relevant to their work. I recently ran across an article that is relevant to my work and it occured to me that it might be worth sharing things that I need to work on for my own improvement. Adam Bryant writes the “Corner Office” article for the New York Times. This week his interview is with Amy Schulman, from Pfizer. While I hadn’t heard of Amy before, her comments struck a chord with me.

Here is Amy talking about her learning:

One of the biggest lessons I’m learning now is having a better feel for when to step out of a situation and when to step in. I do think that is actually one of the hardest things to balance correctly. People want to hear from you. They want your opinion. And if you don’t ever speak up and weigh in, then I think the people you lead will feel frustrated, wondering why you’re hanging back and not saying what you think. But if you’re constantly giving direction and speaking, then you’re really not encouraging conversation.

This balance of trying to let teams work things out on their own vs stepping in and giving direct guidance is something I struggle with as well. I recall a time from earlier in my career when I was a member of the development team. I had built a small test harness that I used to run automated tests against my team’s app. Since the application was just one of several that made up the entire system, I had spoken to a couple teams about adding support in the test tool for their apps as well. In this way, we could have regression tests across the entire system. I was very excited about that prospect. In order for this effort to work, I needed the test tool installed on all of our development and test servers in a common place. This meant I had to go to the system administrators. I described what I needed to the head of the sysadmin group and I remember very clearly his response, “Who do you think you are? You are just a developer. You don’t get to decide what we install on our servers.” I was so stunned, I didn’t know what to say. To top it off, and the relevant part for this note is that this company had an open floor plan and I was having this conversation with the sysadmin right next to the head of the entire development organization. He was sitting there at his desk and he never said a word! I didn’t know him that well before then, but I lost any respect for him right then.

Fast forward to now and I am now the CTO at a new company. I sit out on the floor with the technology team, moving my seat every 6-12 months so I can be closer to the hearbeat of our group. I worry sometimes that I am influencing people’s behavior just by being there. Amy makes the point that

no matter how democratic you’d like to think you are as a boss, you learn that your voice is louder than the others’.

So my first instinct is to stay quiet even when I see someone on the team struggling with a more senior member from another team or group. I find this is one of the hardest situations for a development team. How do they balance their work with the needs of the business? Once when I followed-up on a recurring situation, when I told the group I was getting involved one of the participants made a comment under his breath that it was “about time”. Ouch.

This leads to my final takeaway from Adam’s article on Amy. When she is talking about the balancing act of providing the right amount and kind of leadership

How do you get that magic right? I don’t know. But when it happens, that’s a great meeting.

I love how she acknowledges the difficulties and doesn’t try to act like she has the answers. Thanks Amy (and Adam).

Given the way many technical people seem to “fall into” a consulting role, it is not hard to imagine there are many things about being a consultant people don’t know. Jerry Weinberg’s “The Secrets of Consulting” is a treasure trove of useful information for consultants and employees alike.

The book relies heavily on anecdotes that show different perspectives on consulting challenges. The anecdotes are used to establish sets of practical, understandable rules for how to be a successful consultant, including such activities as how to interact with a client, and marketing and pricing your services. The rules are given names, like “Charlotte’s Law” to describe the importance of marketing oneself for quality positions instead of the quantity of work, and “Pandora’s Pox” to describe the desire for people to keep trying each new fad that comes along in the hopes that ‘this time it will be different’.

While the title of the book is about consulting, the wisdom it contains applies to everyone. Jerry refers to employees as “internal consultants” and frequently specifically mentions how to apply the rules in that case. For example, when he talks about the need for a consultant to work with many clients, he encourages employees to not get stuck for too long in a single job. This is consistent with a theme I have seen from Jerry in his books and workshops - a person is in control of his or her own destiny.

A minor quibble - I read the ebook and this particular one suffers from some early ebook issues like layout issues with chapters that blend together and a high number of typographical errors. It would be nice if these could be cleaned up.

Jerry’s books belong on every technical person’s bookshelf. This one is no exception. That said, if you are just getting started with your Weinberg collection, I personally prefer others like Becoming a Technical Leader: An Organic Problem-Solving Approach and the Quality Software Management series. Start with Quality Software Management: Systems Thinking.

One thing to note - this book is like one of those movies where you need to stay to the end of the credits. The last pages include a list of recommended readings. There is only so much time one can devote to reading and having a book list laid out by Jerry Weinberg is priceless.

Thanks to @lisacrispin for directing me to Pete Goodliffe’s presentation on Becoming a Better Programmer. He captures the essence of what I am trying to say in a much more entertaining and insightful way. Check it out.