Growing as a Manager

Sep 30
2011

I’ve recently spent a lot of time thinking about how to grow professionally as a software development manager. Since I was a programmer before becoming a manager, I first thought about how to transfer some of what I learned about professional development as a coder to my role as a manager.

Programmers have it easy

A lot of options

Let’s think about how a programmer progresses. Of course, there’s experience and time, the greatest of teachers. Even if you have a programmer solve a similar class of problems on a regular basis, if she’s keen she’ll come up with new and better ways of doing things. Add a piece of automation here, a new editor trick there, perhaps a refactor or a domain-specific language – there’s always some opportunity to learn something new.

Luckily, most programmers aren’t stuck solving the same problems over and over – they’re doing different things. This could mean a new programming language (or new techniques with the one you already use), a new platform, a new module or third-party API, or a new paradigm, such as incorporating more of a functional design style into otherwise object-oriented code. Programmers can also change their focus, for instance from user experience to scalability to embedded systems.

Additionally, professional programmers most often don’t have to do it alone. If you run into a database problem you don’t know how to fix, you can go look over the shoulder of the local SQL guru as they optimize your query. If you’re fortunate enough to be on a team where pair programming is the norm, you’ll be in almost constant learning mode. At a standup meeting, at an architecture design meeting, or at a security review, there’s a group of your peers (or superiors) solving technical problems.

All that said, the title of this section is a bit flippant – to really take advantage of these learning opportunities, a developer would ideally have the will to learn, the drive for self-improvement, and the hacker ethos of experimenting with programmable systems. It’s not that this learning comes for free, it’s just that it can be part of the job (or some on-the-side project, or an open-source effort, etc.).

What exactly would you say you do around here?

The pleasure's all on this side of the table, trust me.

So now, back to the land of management. What does a software development manager do, and how would one go about improving those skills?

Roughly speaking, you can break down what I do into four areas:

  • People management. This includes conflict resolution, career development for my direct reports, and managing up.
  • Project management. This involves task prioritization, risk assessment, project tracking, and scope management.
  • Process / team management. This is broad, but in part consists of promoting technical and team best practices, and focusing on how the team does their work.
  • Technical guidance. Although I’m not the most senior technical person on the team, I have substantial product experience and a higher-level context that proves useful during in-depth technical discussions.

Of course there is overlap. What is a team if not a group of people? Choosing continuous deployment could be process or project management, and encouraging pair programming is part team management and part technical guidance. The list goes on and on – I’ll stick with the above demarcations tfor now.

How do you grow?

There are several paths towards professional self-improvement, but I’ll lump them into three broad categories: Experience, Training, and Self-Study.

Experience in this case refers to professional experience, and covers most of what I talked about above with respect to programmer development. This is the knowledge that comes from trying new things, learning from mistakes (both yours and others’), and paying attention to what works in various situations, all as part of your day to day work life. There is always some sort of experiential learning to be had, should you choose to take advantage of it.

Training is another way to learn, and can be helpful in circumstances where there’s a specific skill set to be learned that is too broad to wait for experience to teach, too critical to be learned through trial an error, or too time-sensitive to be learned through self-study. School and certification courses are obvious forms of training, but I also count mentoring (external or within your company) and conferences under this heading.

Self-study is a broad term. and I use it here to refer to everything from reading blog posts and books, to podcasts and forums or user groups, to side projects and open source contributions. Self-study is the most accessible form of learning for most people in this profession, since it is plentiful and often free, but it is often the least taken advantage of.

Naturally, like the overlap in the management responsibilities above, the distinctions between these categories are not hard and fast. Would MIT Open Course Ware count as training, or self-study? Work experience often has aspects of self-study, even though it may not self-directed. A conference may be training, but what about an unconference?

So what are you doing about it?

World's Best Boss

Aspiring to greatness

Now that I’ve laid out the loose definitions for the types of learning I might undertake, as well as the areas in which this learning could be applied, I’ll get into what and how I’m trying to learn.

People management is an area where I think there is a limitless amount of experiential learning to be had, and it’s one I’ve been focusing on more recently.  Even if I was managing the same people for 10 years, they would change, I would change, and the project would change, so there would be new challenges and opportunities. That said, I have been pursuing self-study in this area (mainly through blogs, books and podcasts), and the upcoming Much Ado About Agile conference has several talks and tutorials on the subject of people.

Project management is something I do as part of my job, but I’m not really a project manager. I have experience working within my company’s project framework, but there’s a lot of inertia to overcome to change anything since it’s a framework the entire company uses. This is an area I’m not putting a lot of effort into improving on my own time, since it’s not a primary interest and there’s relatively little I can do about it in my current position, but I’m always on the lookout for things that I can improve during my day to day tasks.

Process and team management is where I’ve spent a the most time learning, through experience, training, and self-study. I’ve followed the Kanban community, posting questions and comments, and even helped review a great book on the subject. I’ve read books by Mary Poppendieck, Tom DeMarco, Esther Derby, and more, and my to-read list just keeps growing. I’ve attended and spoken at Agile meetups and conferences. I’ve tried to be an Agile coach for my team (which can sometimes be difficult). Although this is where I’ve focused most of my efforts, I’m starting to back off a bit here in favour of People- and Technical-centric learning, primarily to round out my management style.

Finally, learning about technical management. Although over the years I’ve done some self-study on this, reading books on design patterns, lean and agile development practices, and architecture, I haven’t been as rigorous about this as I could have been. Part of it has been that I haven’t been coding at all (maybe a few lines every few weeks), a situation which I’ve started to correct. Picking up new technologies, even if I’m not using them at work or for any serious projects, helps broaden my perspectives when faced with the challenges I do need to solve at work, providing me with a bigger technical toolkit. I’m also getting more involved in security reviews at work, and have recently had some work-sponsored training by a security expert, and I hope to get some further training on the technical track of the upcoming conference.  While I don’t know if I’ll ever go back to primarily being a developer, I think staying sharp technically is an important part of being a development manager.

Your turn

Thanks for making it this far! Do you agree or disagree with my assessment of the learning opportunities for programmers or managers? Have anything to add? Let me know in the comments.

Struggles with Kanban

Feb 13
2011

This past year was probably a turning point for me in terms of getting involved with a larger community on cutting edge issues, specifically the Kanban community. Although my team achieved great successes in the past year, shipping 37 different software releases and maintaining high quality standards, I can’t say that I’ve really seen too many benefits from Kanban thus far. Don’t get me wrong – I still think the method has a large number of merits. It’s really more that I’ve been barely doing Kanban.

The year is a continuum, of course, and I can’t say that I didn’t do anything with respect to Kanban all year. My knowledge about the team and the method improved throughout the year, culminating in a Kanban “relaunch” in the new year. That’s been going well, and my current approach is much more in line with what the method prescribes, but that’s a subject for a different post. Today I’ll reflect on what did and didn’t work in the past year, and why.

First, I’ll cover the highlights. Even the very limp version of Kanban we were doing afforded us some structure to build on and learn from. With a visualized workflow and explicit work in progress limits, the team engaged in conversations around how much parallelization was too much and what the appropriate size of work items was. The beginnings of explicit policies emerged, blocked items were noted and prioritized, and the team successfully delivered on their commitments.

Now for what didn’t work. Explicit policies were few and far between, which led to the rehashing of several topics as well as too much unnecessary management intervention (tie breaking, direction, clarification, etc.). Metrics about lead time, cycle time, and work in progress were not kept – I always thought there would be a better time to start, such as the beginning of the next project, and worried about missing important metrics or recording useless ones. The lack of classes of service also provided some discouragement for data-gathering, as two different tasks in progress could be two orders of magnitude apart in difficulty. Without such data, our Kanban system was being used primarily for task management instead of as a process of evolutionary change. Finally, with a dedicated, embedded customer / product owner on the team, and with an existing culture of openness, there was no cadence at all. Releases, retros, and queue replenishment were all ad hoc, which prevented any rhythm from forming.

Although our work system is still, and will always be, a work in progress, all of the above difficulties have been addressed. I now have a month’s worth of data, spread across 5 classes of service. We have a weekly cadence for queue replenishment and retrospectives; we’re in the middle of a large project, so we no release cadence right now.  Policies are explicit and are up for review during the retrospectives, or during the week if the policy is wrong or dangerous.

My next post will outline how the team’s system works, some problems we’re still trying to address, and what we’ve learned so far.

Retrospectively Agile

Jan 22
2011

My team has recently adjusted some of its process to adapt to changes in our organization, and I thought that this was a good chance to get on a regular retrospective schedule. As a team, we are very good at communicating, and we are constantly reflecting on successes and failures. Because we address most issues in real-time, weekly (then bi-weekly, then monthly, then occasional) retrospectives became relatively quick, limited-value rehashes of the tired old “What Worked / What Didn’t Work / Actions required” formula. If we were going to start doing retrospectives more often, I wanted to make sure that we were getting something out of them.

Chatting with Esther Derby at the recent Agile Vancouver conference, and seeing her present, made me quite interested in her books. There’s been a copy of Agile Retrospectives sitting around the office that I had skimmed a few times over the years, but now that I was intent on improving my team’s retrospectives I sat down and read it cover to cover.  It’s a great book with many sample exercises that have proven effective for a variety of teams, but it’s probably the psychological and sociological theories and general frameworks for group learning that I found the most interesting.

Our first of the “new” retrospectives was on Tuesday of this week, and I think it could be considered a success based on the feedback I’ve received. It was great to see that, despite some relatively major changes in focus for us, the team is generally on the same page with respect to how were are working together. We came up with a few explicit actions, but my primary goal for this retrospective was to get a baseline of the team with respect to their thoughts on the current project, adherence to team values (which we defined), and general team satisfaction.

We’re definitely going to maintain our current practice of doing immediate retrospectives, root cause analysis, and other corrective techniques, as it’s working well for us. I think these new retrospectives will be a chance to look at things at a higher level, measure trends, and ensure that the team is still aligned with the company and with each other.

Whither the Change Agent?

Jan 07
2011

One of the roles that I see myself growing into as time passes is that of change agent. I don’t mind speaking up when I see problems, I’m dedicated to seeing problems solved even if it won’t happen immediately, and I don’t get discouraged if there is resistance or setbacks when implementing change. I’ve been lucky enough to be leading a team where I can experiment with new ideas and have a lot of control over how my team works.

However, when I look at professionals in my field who are interested in team and organizational improvement, they are almost always consultants. Does it have to be this way? I can see the benefit – moving from company to company, the rate of feedback is much faster, and you can learn what works and what doesn’t work much sooner than you could working within the same system. Also, there’s always this old quote from Deming:

“As a good rule, profound knowledge comes from the outside, and by invitation.  A system can not understand itself.”

Is it that companies refuse to accept major change initiated from within the organization? I’ve heard this repeated many times (though I’ve never seen any studies), so that could account for the lack of “famous” internal change agents. It could also be that people who are genuinely good at turning companies around demand too high a price to be a permanent employee. Alternatively, maybe there’s an inherent bias of contractors and consultants to be more vocal about their methods, previous clients, and successes, as it helps them gain new business.

All that said, I like working in a single company and have always thought that I’d hate being a consultant. That distaste is changing a bit – I think it’s mostly the gathering of clients / insecurity that I’d dislike, as opposed to the nature of the work – but I’m still not very interested in jumping ship and becoming an entrepreneur.  Of course, all of this may be due to inexperience. I’ll be the first to admit I that have relatively little experience in the industry.

For now, I’m still in a good place. I run a small team in a large company, and there seems to be some opportunity for change that I may be able to help out with, so I’m definitely not out of growth options in this area. I try to keep as up to date on modern methods as I can by reading books and forums, talking to other professionals, and airing my ideas publicly so they can either be torn down or validated. Still, it’s interesting to think of the future, and wonder if I’ll ever have the desire (not to mention capability!) to go solo.

Ex-P(rogrammer)

Jan 04
2011

For the past two years, I’ve been managing a software team. This role has a lot of requirements, and I think I’ve been fairly successful, but there’s one thing I used to do that I never really do any more – program. Sure, I review a lot of code, and occasionally pair with people or help problem solve, and when asked I give my opinion on architecture, but it’s been a while since I’ve sat down with some code to myself and tried to get something done.

Well, I’m trying to change that. I’ve realized (through a few false starts) that I’m not going to pick up a new programming language, hop into an open source project, and start contributing. I think I have the ability to do so, but definitely not the motivation. Instead, I’m going to chip away at small improvements in my product’s code base that will hopefully make life easier for my team. For now, I’m going to stay away from changing a lot of production code – I want to ease myself back into the groove slowly, and while I’m not afraid that I’ll write a bunch of awful code and ship to customers, I don’t want to get too bogged down in our automated test rig at the moment.

I’ve got two little projects going on right now. The first is to add Perl::Critic tests to all of our packages. Perl Critic is a highly configurable automated code style critic, inspired by Perl Best Practices, that can help you detect all sorts of wrongness in your code. It’s easy to add a test, and then a lot of fun (for various definitions of “fun”) chasing down all the failures and getting your code up to snuff. I’ve only added the test to one package so far, but it’s a package with over 100 files so it took me a while to clean up. Subsequent packages should be easier, and it should be self-enforcing going forwards (as all of our tests are required to pass before a build is produced).

The second project is to ease our use of CPAN modules by rewriting part of our build system to use cpanminus. Our current system makes it difficult to import CPAN packages, or even upgrade the ones we have easily, so I think this could really benefit us. Replacing some of the packages we’re still using from 2002 would be most welcome, and there’s a lot of exciting stuff being developed for Perl right now that would be ncie to experiment with. So far I’ve got just been playing around a bit with cpanminus, but I’ve already managed to find a bug (I think – I’ve filed it anyway). I may write more on this once I’ve got it working.

These aren’t exactly monumental bits of code I’m fiddling with, but it feels good to get back into it, and the important thing is that I’m actually motivated to do this coding. I have no desire to go back to being a full time developer, but it’s nice to keep up my technical skills.

Thinking of Agility in the Enterprise

Jan 04
2011

Reading Scott Ambler’s recent post on Reworking the Agile Manifesto got me thinking about about Agility in the Enterprise, a subject I have no experience in but want to learn more about. Here’s a bit of background – I hope to blog more on this subject as my knowledge increases.

I’ve been involved with Agile software development in varying capacities (developer, coach, manager) for just over 5 years. As such, I feel like I have a pretty good grasp on the key concepts, what it takes to succeed, and pitfalls to watch out for. That said, all of my experience is with one company, and pretty much on one team, so my sample size is quite small. Additionally, my small team has been quite fortunate in that we’re the one of the only teams in my organization that doesn’t have critical dependencies on other teams. We have almost complete control of our end-to-end value stream, my developers feel close to customer issues, we have a cross-functional team with everyone that’s required to ship the software, and we have an on-site customer surrogate (our product manager, who talks directly to customers and other stakeholders frequently). We release software frequently, are quick to respond to customer needs, and are limited only by our headcount. It’s great – my team is being recognized as a standout in the organization, and sales is quite happy with the way we deliver software.

Why is this a problem? Well, my team represents less than 5% of our total worldwide engineering headcount. The other 95%? There’s a few of them that operate within similar parameters as my team (including another team in my local office), but the vast majority of the company is in a very different situation. They have larger teams with much larger code bases, where coordination is required between many geographically distributed groups, and they’re required to support a huge variety of platforms. Project scope is multiple times (or order of magnitudes) larger than projects I run in terms of effort. Additionally, most of the teams outside of my office have a very different team structure; development is segregated from product management, and both are segregated from QA. This part of the company is significantly older and more established than my team.

I believe in the agile way of thinking and think it has a lot to offer my company, and I would genuinely like other teams to see some of the benefits that my team has received from applying agile practices. That said, without having any direct experience at scaling agile practices, I feel a bit limited in both confidence and knowledge. My recent interest in organizational learning, combined with an opportunity I’ve been given to get more involved in the codification of some our processes, should help me move towards being able to apply my interests at a larger scale, but for now I’m very much in learning mode. I’m okay with that – I’m just looking forward to a time where I can help out other teams in other situations with specific advice instead of just paraphrasing the manifesto.

So You *Have* Heard of Us

Jan 04
2011

Even though I work for company that has millions of end users and is one of the leaders of its industry, whenever I tell people where I work I’m met with blank stares. Why? Unlike some of our competitors, Sophos doesn’t sell directly to consumers (you won’t find us for sale at Best Buy, nor are we bundled when you buy a Dell) – we only sell to business, governments, schools, and other organizations. Thus, blank stares. Luckily, Sophos has come to my rescue and released a great free tool that’s already raised their profile among non-business users – Sophos Anti-Virus for Mac (Home Edition). Best of all, this release is free!

Now, I know what some of you are thinking – why would I bother with anti-virus for my Mac? Well, Macs are not immune to malware, and they can host Windows malware that can infect friends and family. Sophos Anti-Virus for Mac is featured on Apple.com, is mentioned as a staff pick, and has been positively reviewed in several places. I’ve been running this for a while, and it’s hardly noticeable, even though I have hundreds of gigabytes of files on my Mac. The one time where I did notice it is when I downloaded a “demo” of a program (a torrent of something that I wanted to see the interface for), and it immediately detected a keylogger in one of the files.

If you have a Mac, there’s no real reason not to be running this.

Visit Our Friends!

A few highly recommended friends...

Pages List

General info about this blog...