Change Brings Change

Posted by steve | Management & Leadership | Tuesday 27 May 2014 9:21 pm

In the period of just a few weeks, 3 very dear friends of mine have either changed jobs or are in the process of changing jobs. I’ve known all three for 10+ years each. What is interesting is that each of these friends are self actualizing. They are choosing to change jobs. Making choices about their careers without having or allowing someone else to choose by either action or inaction.

They have all picked excellent new jobs and I’m excited for them. In the cases where I see them everyday in my current job, I will miss them when they are gone.

I’ve seen this pattern before. First, it is a good sign isn’t it? While we may never see the IT jobs market we all experienced in the ’90s again, portions of the economy are showing real signs of investment again. The other encouraging thing I’m noticing is that more seasoned veterans of IT development and management, like myself and my friends, are both getting noticed for their own value and we are gaining clarity about our roles as well. The ever present pressure to keep costs down by seeking less expensive labor will be with us for some time, but the value of the skilled talent is also starting to become more obvious as the real keystone to how companies can create the future they want. It is an exciting time.

When I was a manager at a fairly large software development shop years ago there were many interesting lessons to be learned. At that time I was part of a team where there were employees that had been with the company for over 20 years. They knew how things worked and why. Yet we were careful in ensuring that creative voices could be heard. I was one of those voices and enjoyed that experience. New ideas were encouraged and looked at seriously. The funny thing was, and see if this doesn’t sound familiar where you work today, the senior management in the company changed about as often as fashion trends. The folks that did the work, the coders, kept on while the leaders kept deciding what they wanted to do. And that was one of the funniest examples I remember. I had an employee on my team that had been with the company for maybe 18-20 years before I joined. It was important to listen to him. He was smart and he knew what was real and what was “noise”. I’ll never forget this part. One week we all received an email that the company had reconfigured management again, new faces, old faces, silos or not. Another change in configuration. Anyway this guy opens up his desk drawer and files the new org chart away. Then he says to me “Want to see what the next org after this one expires will look like?” I was curious about what he meant. He’d been keeping every org chart for over 20 years. And sure enough if you matched the pattern with a previous one you could see what the one that followed it a few years later looked like. It was amazing.

So is that a bad thing? Like everything else in life, a little yes, a little no, and “do it with moderation” someone wise will add.

I’ll cite another example.

One of the jobs I had was Product Manager of an IT team for a manufacturing firm. Because it was a relatively small company, and because the company had only 2 real product lines, if you were a Product Manager you were well known and visible. And I got to know the President and Vice Presidents on a first name basis because we talked frequently. I remember that the manufacturing shop, when I joined the company, was running a standard 40-hour work week single day shift. All employees on the manufacturing floor worked 8 hours a day for 5 days a week unless there was overtime. One day the Vice President of manufacturing had the idea that he would change the structure and still have everyone work 40 hour weeks, but change it to 2 shifts that overlapped in such a way that a single employee worked 10 hours per day for 4 days per week. Some folks worked Monday through Thursday, and some Tuesday through Friday. You get the idea.

And guess what happened? All the benchmarks they had for productivity went up. This stayed that way for several years (I was with that company for 13 years) and got to see what I’m about to describe happen more than once. After a year or two when things felt like they were in a rut, the schedules changed. Still 40 hours per week but now everyone was switched back to working 8 hours per day and 5 days per week. Guess what happened? Benchmarks for productivity went up.

My take away was that introducing change can have benefit.

People make changes in their lives for so many reasons. Things I’ve noticed include:

  1. Someone gets married
  2. Divorce
  3. Kids go off to college
  4. A neighbor moves out or in
  5. Someone close to you dies
  6. Someone gets fired or laid off
  7. Someone you know changes jobs
  8. A friend buys a new car

The saying I’ve adopted is “Change Brings Change”. When people around you change their lives, or have their lives changed unwillingly, it is human nature to pause and reflect about the decisions you make in your own life. As a manager I came to expect changes in a team if any person in that team made a change. If someone left, almost without fail, someone else leaves for a new job too. If a team member buys a new car, someone else will very soon too. It happens.

Should you change things for yourself just to break a pattern? I think it is worth personal reflection. It cuts both ways. You may realize that you are living in a “rut” or have compromised on something important to you too many times. Or you could realize what you have to be thankful about your world and life as it is. We all know people who are always complaining about their job and sometimes hopping from job to job but not really improving their lives.

Change may be good. It may be disruptive. But one thing for sure I notice is that you owe it to yourself to reflect on your life too. Maybe you need to invent your own future, or maybe rededicate the one you have already made? It never hurts to look at things hard in the eye.

One thing for sure. Change will wake you up.


Pair Programming Anecdote

Posted by steve | Management & Leadership | Wednesday 22 January 2014 8:41 am

Update: I just realized that Martin didn’t write the original Blog post I reference here. I found it because of tweet he posted. Sorry about that Martin.

This morning I read a Blog post from Martin Fowler, an individual I admire very much professionally. I don’t know much else about his non-professional life except that I know he also loves modern board game designs too. Anywhere here is a link to his post where he contrasts his experiences with Pair Programming teams and Code Review oriented teams.

As many who know me professionally, I’m also an advocate for what Pair Programming can do when it’s done well — having worked in a Pair Programming environment for a 10+ year stretch recently. Because of that experience I have also seen where it brought no value. Like anything else, there’s no simple pill or solution to what is required to be successful, and often you need to by dynamic about your processes because things change. And also vigilant. I’m reminded of Rebecca Wirfs-Brock‘s presentation at OOPSLA years ago where she posted a bumper sticker “Shift Happens”.

My reason for my own post this morning, after reading what Martin wrote, is that I was reminded of an anecdote from back when I used to manage a Frameworks Development team. The company was a substantial software development shop with maybe 500+ developers on site. This was back in the late ’90s. I was introducing the team to the concepts of eXtreme Programming and Agile development concepts such as code refactoring. In fact I purchased copies of Martin’s book on refactoring and had passed them out to all of my team members. We went through the book, reviewing a chapter per week. We also talked about Pair Programming. At the time the overall development shop was anything but agile. There were senior managers so focused on the tactical, seemingly “by-the-minute” costs, that discussion about putting two very expensive ($100K+) programmers together on a single development workstation was a daunting prospect. But I discussed it openly with my team and wanted us to try it out in small “doses” to see how it would work.

One of the senior developers, having been there for easily more than 20 years, totally surprised me by saying “Oh, we do Pair Programming here already sometimes. When the code HAS TO BE RIGHT.” He described a familiar scenario of a team finding a serious defect in the eleventh hour before a software freeze. It was not uncommon that two, often very senior, developers would look over each other’s shoulders as a code fix was made to ensure there was no risk of introducing other problems. When it had to be right, they paired on the code.

I get it. It addressed the problem by providing one of the benefits of Pair Programming: on-the-spot code review by a capable peer. And for that brief period of time no one questioned the cost because everyone implicitly understood the cost of failure was higher.

There’s a lot to think about from that experience.

I want to provide another reference link. This is to a Blog Post from another old friend and code-warrior, Blaine Buxton. He and I worked together several times in our careers, over a span of easily 15 years, and I’m sure the respect is mutual. He wrote an insightful post about the things that can go wrong when Pair Programming is not the answer. I know exactly what he’s talking about, having worked with him on the same team where he experienced the challenges described. Here’s Blaine’s post.


Leadership is Giving Up Control

Posted by steve | Management & Leadership | Monday 30 September 2013 1:24 pm

I realize that posting on a personal blog with an opinion about management always includes with it the risk that the management team you work with in the real world may read it. And they may get the wrong idea. So let me just get this out-of-the-way first. The management team I work with, regardless of the fact that they may read this or not, is outstanding and teaches and instructs good values of leadership. No kidding. In fact, who’s kidding who? That’s why I choose to work for them.

This leads me to the reason for this post. It occurs to me that an outstanding manager will delegate responsibility to employees as far as possible. Let me explain what I mean by that. Encouraging the employees to take responsibility, make decisions, and overall demonstrate responsibility is a great thing. And the right thing to do is to mentor the employees to be better at handling and understanding those responsibilities. A great manager finds ways to make other great managers. A poor manager tries to keep everything under control tightly. Fear vs trust.

With the right kind of shepherding as an example of leadership, the employee will know precisely what to do. And the discipline must also exist to recognize where our own responsibility as management lies as we deal with delegating to others. If they make a mistake, it’s not our place to give them a lot of crap about it. Rather to recognize if our own instruction was inadequate or if it just couldn’t be helped with the existing knowledge. A team I once worked with had a saying that “the person working against you may just not have enough information.”

I’m quite fortunate to work as part of the management team that expects that kind of responsibility from all of us. And we get feedback if we need help. Rather than try to control what everyone does — and you know you’ve met those managers before — they mentor you and give you the authority to do what is needed. It is a marvel to experience if you’ve never been expected to act like a stake-holder before.