One-on-Ones on a Pair Programming Team

One-on-Ones are a well known management strategy. They help reduce communication misses, keep everyone on course and provide an easy platform for feedback. I’ve done them throughout my management career, but the past few years I had a few start and stops with them.

My scenario over the past few years has been working as an engineer and often a tech lead on small teams where we paired as much as 80%. Sitting side by side and rotating pairs often led me to experiment with skipping out on one on ones. If you’re having regular conversations over the code, do one-on-ones serve enough of a purpose?

I decided they were important enough to restart after my first year on the new job. Part of my reluctance was the need to come up to speed on a number of technologies. I skimped on spending time for tactical management tasks. I relished staying deep in the code and design, but I should still have carved out the time for one-on-ones.

When I transitioned to leading a new team about 6 months ago I again let the one-on-ones slip off my radar. I told myself I would restart them after I felt out the new team. Turned out I got lazy and took 6 months to restart them. Even on teams that pair and sit in close proximity, some conversations never come up and it’s rare to discuss items like career aspirations when the whole team is housed at one long table.

I have made a single adjustment from my old style where I ran 30 minute one-on-ones once a week. For my current team:

  • Scheduled for 30 minutes.
  • Most of the agenda is up to the employee, and sometimes we discuss future career type goals.
  • The last 5-10 minutes are for me, news I need to pass on or lightweight feedback.
  • Generally the one-on-ones average about 15 minutes, but they’re still scheduled for the full 30.
  • I rotate through all of them one after the other so with 3 we’re often done after about an hour.
  • If we miss a week for some reason it’s not a big deal, since these are weekly.

My Biggest Career Mistake


My software career path has been a planned affair for many years. It started out as a happy accident with some exposure to a very early internet startup and an opportunity to build out a few web sites. It only took a few months to determine I really liked doing web development and I began my love affair with the computer section of local bookstores, devouring titles in an effort to come up to speed.

As my career progressed I always stepped into the next job to take on new challenges. I went from Perl CGIs to Java, from in-house development to professional services, and from being an individual contributor to managing a development team. The learning curve was exhilarating and enjoyable and when the position ran out of challenges I started looking at new opportunities. Learning new skills is a large component of what keeps me happy on a daily basis.

I didn’t realize it at the time, but I made my biggest career mistake on what seemed a very orthogonal concern about 5 years ago. At the time I was managing a corporate development team, having led them through an Agile adoption process that had been successful at a team level, but generally a failure at the larger corporate level where the management teams simply weren’t interested in changing. Having accomplished much of what I could I started a process of looking for new opportunities again.

My big mistake? Taking on a large home mortgage. In that year we moved from a nice modest home with a very affordable mortgage into a larger remodeled house with two bathrooms. Both my wife and I were advancing in our careers and bought into the idea that while the mortgage was a bit tight to begin with it wouldn’t seem that bad as our salaries grew.

At the time I started my job search I was aware that I had become disillusioned with corporate development. I loved mentoring up teams and bringing them up to speed on testing, refactoring, and CI, but I had begun to doubt that I could win many battles at the CIO level with making a greater impact. I pursued several opportunities at small software firms that sounded really exciting, but I ultimately said no because I wasn’t ready to take even a small drop in salary. I ended up taking another corporate management position at a company that was 7 years into a 200 million dollar death march project. There were some other warning signs going in beyond the death march project, but the compensation package was very respectable and in line with my new mortgage.

Up until this point my criteria for switching jobs had been:

  • The chance to make a real change in the organization
  • The opportunity to learn new skills
  • Working with great people who I could learn from

At the time I convinced myself the positives outweighed the negatives, but again it was really the mortgage that made the difference. The job had aspects of my criteria in it, but I had turned down several others that really fit the criteria completely, but involved taking a salary hit.

It took four years for me to undo the side effects of making the wrong career decision.

Fallback Plan in Action: From Software Manager to Developer

Everyone relishes the confidence of a having a backup plan if everything falls apart. For myself as a manager it was knowing I could always go back to development if something unexpected came up. After 10 years as a development manager, I got the unfortunate call to follow my director to an unannounced meeting first thing in the morning. Turns out the CIO had decided the organization didn’t need developers and could get by with contractors so there was no need for a development manager. My director would depart the company as well a few months later.

I was in a state of shock for a few days. Sacramento is a small IT market normally and finding open development management positions is fairly rare. I explored a number of options for the first month afterwards including biting the bullet and taking a great job in the Bay area but living with a horrible commute and lousy family life. For many reasons I choose family over a nasty commute.

I came back to the plan of returning to a developer/architect/tech lead role. I hadn’t done day to day development in at least 5 years, but I’ve always kept up my skills with home projects and taking on the tasks of running infrastructure tools like source control, CI servers , wikis, and functional testing tools. I really enjoyed managing development teams and moving obstacles and really growing the skills of my team, but now it was time to focus on myself.

Fear was right up front. I felt like an impostor in the first few development interviews all of which went well despite this. I’ve never felt a high degree of confidence in my abilities and always felt the need to prove myself. With my background as in professional services I eventually got acclimated to the feeling that I was an impostor working on the client’s project. It motivated me to spin up incredibly quickly so I wouldn’t be exposed as a fraud. I’m still not sure this has been the healthiest approach, but I’m still working through my affliction with the Impostor’s Syndrome.

Another factor was figuring out how comfortable I was with making less. Development managers simply make more than senior developers. I’m certain this is the wrong approach in many cases as I always felt at least my top few people were more important to the company than myself, but HR departments really like hierarchal salary structures. So diving into development was likely to mean a salary hit. I have a wonderful wife, two kids, and a hefty mortgage. The prospect of taking a startup job with a firm that was a using new technologies was enticing, but taking a big salary cut was going to be very hard. Lesson learned with the mortgage, sometimes the nice new house isn’t worth the career choices it forces you into to, but you end up making some compromises in life.

I ended up deciding I had to hold out for a well paying position even if that meant working for less exciting companies and technologies. It probably meant a lot of Java/J2EE given my background instead of Groovy/Ruby or mobile development.

Anyway after a month or so of doing some big career thinking, visiting family and friends, and polishing up some slightly rusty Java chops I dipped my toes back in the water with a couple one off gigs for a former employer. I took on a mentoring an organization through development tool choices and how to guide their staff on working with these new tools. From there I took an assignment to do a custom WebLogic course for a client. It was a week long course which I felt I could ramp and cover, but brought back a lot of lingering doubts.

I’ve done many presentations over the years ranging from an hour or two to a half day seminar. I feel very confident in the ability to deliver them with a high degree of quality. Before this I had done two week-long courses in the past and survived them both, but walked away from each feeling as though I had done a horrible job. Keeping a class engaged and interested in a topic for an entire week and knowing it deeply enough to answer almost any question is quite a tall order. So the WebLogic course was a big challenge.

I spent a week immersed in the course material and working through the labs several times after building a VMWare image. I prepped in front of the director of the company, feeling like I was going to fail. I delivered the course, and spent 6 hours every night reviewing everything for the next days class. I was actually shaking stood up to deliver a lecture on a new section. The good news was even though I felt like it hadn’t gone that well, I got glowing reviews from the students.

Soon after I dived full time back into consulting with a company. I had many assignments helping mentor development organizations and a ton of classes and custom class deliveries. In 6 months I actually taught 21 different week long courses. The work was brutal, but eventually I got the confidence in my abilities back, and I can almost effortlessly present on technical topics with just a small amount of prep time. Over the last 6 months I’ve come back to almost full time coding and even gotten to do a nice Groovy/Grails/jQuery project utilizing 1 week iterations.

I’ve read many times about how many technical managers make the mistake of letting themselves get promoted and then they can’t let go of the coding. And many technical managers point out the need to focus on the management tasks of the job. My approach to this was to focus on the management of my team, but to keep my skills fresh by doing side projects at home, presenting at user groups, and doing code reviews and maintaining build servers at the office. I don’t think this is the common approach of development managers, but it’s the only approach I’ve felt comfortable with. I do remember feeling some camaraderie with Rands (of Rands in Repose) as he proposes:

“I’m still cringing. Someone is already yelling at me, “MANAGERS OWNING FEATURES??!?!” (And I agree.) You are still a manager, so make it a small feature, ok? You’ve still got a lot to do. If you can’t imagine owning a feature, my back-up advice is to fix some bugs. You won’t get the joy of ownership, but you’ll gain an understanding of the construction of the product that you’ll never get walking the hallway.”

Rands

So the fallback plan is just as important as the financial advice you always get to make sure you have at least 6 months of salary socked away so you can ride out a layoff. Rather than fighting for nearly nonexistent management positions in a bad economy I was able to step into development and do important work. While I love management there are aspects of development that I’m very passionate about and I may continue on this course for the next few years. I’m sure I’ll return to managing a development team as it’s in my DNA, but for now I’m enjoying firing off a ‘git commit’, seeing lots of green tests passing and building a quality app in short iterations.

Recruiting for Passion: Creative Job Descriptions

As a new manager recruiting for the first time you’ll find HR will usually provide you with a job description template. You’ll read it, laugh at how generic it is, and then try to do a bit of modification. That’s a futile effort. (Though depending on the organization you may have to leave pretty close to the strict confines of a template, in that case you’ll be working with a few custom bullet points you can work in.)

You’re actually looking for the most talented, passionate developers you can find given the opportunity, your location, and the relative pay rates provided. So how do you attract those people with a generic job posting? Instead you rewrite the position from scratch and ask for things like writing plugins to open source frameworks, giving presentations at conferences, or writing a technical blog. You want to attract developers who care about their craft and are going to bring up the overall level of your team.

So in short:

  • Keep it short a paragraph or two and bullet points. The meat of the content is in the bullet points.
  • Explain the challenges of your environment, if you’re a hardcore waterfall shop trying to shift to Agile be upfront.
  • Explain that mentoring is part of the job.
  • If you have the control you can even write the job description in a programming language.
  • Be very clear that bringing your passion to work is encouraged.
  • If you’ve won some of the wars with the furniture police, explain the nice hardware and multiple large monitors that are available, or even semi-private offices.
  • If other members of the team have some public blogs, or open source projects point to those as well to give them a feel for the team.
  • If you’re not in Silicon Valley or New York, sell the upside of your region (probably cheaper living).
  • If HR will let you point to some of the targeted job posting sites like 37 Signals or Stack Overflow.

Developer Expectations

I came across a note of mine from last year on my baseline expectations for developers:

  • All code is checked into source control on an hourly basis or at most daily.
  • Every project has an automated build. (Maven, Ant)
  • All projects are setup in continuous integration (Hudson)
  • All code follows the current Java/Groovy coding standards.
  • Unit test coverage of new code must meet a 70% target. TDD is preferred.
  • Code reviews or regular pair programming are required.
  • Code should meet a standard of low cyclomatic complexity through refactoring and design.
  • Some level of functional, integration, and acceptance tests should be performed.
  • High value documentation is maintained.