Taking Responsibility

I’ve been a bit hesitant to write something about this, since I think it’s something of a delicate subject . . . it’s just a bit odd to write about, knowing that people I work with will read it.  But it’s an important enough subject, and one that I feel strongly enough about, that I think it’s finally time to say something about it.

For those of you who are reading this and don’t know, my technical title is something like “PolicyCenter Architect.”  Since I think the word “architect” in a software context has taken on all sorts of horrible connotations (it conjures up images of people who draw boxes and arrows but don’t actually write any code themselves), I tend not to use it personally.  Instead, I tend to think of my role on the team as being the guy who should be blamed when things don’t work.  Not the guy who should be blamed when something he did doesn’t work, but just the guy to blame, period.

I know it’s something of an extreme stance to take, which is why I think it’s worth an explanation.  Coming at it from a different angle:  my job is to make sure that the project doesn’t fail for technical reasons.  If the code is buggy, or it doesn’t perform, or it’s not flexible enough or in the right ways, then I’ve failed to do my job.  It doesn’t really matter why, or who wrote the code:  I’m supposed to make sure that doesn’t happen, and to do whatever it takes to get there.  In some ways that’s fundamentally unfair, since I can’t possibly control everything that goes on, yet I’m personally responsible for it anyway.  I honestly think that’s still how it has to be.

Taking responsibility for things is a powerful thing, especially when they’re things that you don’t directly control.  Part of being a professional is certainly taking responsibility for your own work, and not passing the blame to someone else when things go wrong.  But I think it’s even more powerful to simply say I will not let this fail.  Full stop.  But I think the only way to really get to that mindset is to take responsibility for that failure; otherwise, there will always be the temptation to throw up your hands and pass the blame on to someone else, and at the moment you absolve yourself of responsibility for that failure you’re lessening your personal drive to do something about it.  The other thing that needs to happen is that you have to accept the fact that things could fail, that you have limited control over that, and if they do it’ll be your fault anyway.  Failure sucks, and it’s a hard thing to swallow:  on my current project, it took me about five months to really come to peace with the fact that I was going to have to make a lot of very, very hard yet speculative decisions and that my best efforts could still end in failure (and a very, very costly failure at that).  Once I finally did, though, I slept a lot easier, and it freed me up to do better work than I otherwise would have been able to do.  Whatever role I managed to play in making the project succeed, I think it was significantly aided by the fact that I got over being afraid of screwing up.

I think there are three primary reasons why taking responsibility and blame for things you don’t actually have control over works out.  First of all, it forces you to do whatever you can to minimize that chance of failure.  Since you don’t have complete control, you can’t get it down to zero, but you sure have an incentive to get it there.  And not only that, but you have an incentive to do what’s right for the project as a whole, not just for your part of it or for you personally.  That extra drive, extra motivation, and whole-project orientation will lead to you doing more to make the project succeed than you would otherwise.  Secondly, it lets you make hard decisions under uncertain conditions.  A lot of projects fail simply because no one is willing to make those decisions; it’s always less personally risky to leave things as they are, or to take the well-trod route, or to pass the decision off to someone else even if they’re not in the best position to make the decision.  Sometimes, you’re the best person to make the decision, and you just have to be willing to do it.  Sometimes you’re not, so you have to pass the analysis off to someone else, but in order for them to really make the best decision they can they have to know that you’re going to back them up and not blame them if it goes wrong for some reason.  Lastly, while I really have no idea what anyone who works with me really thinks, I like to think that having someone willing to take that level of responsibility lets everyone else on the team do better work too, since they know that someone has their back, they can focus on doing their best instead of worrying about trying to look good, and they have the freedom to do what they think is the right thing.

It’s worth mentioning that the flip side of taking the blame is not taking the credit.  I’m not the first one to point out that good leaders should accept blame and deflect responsibility, but I think it’s one of those things that it’s hard to repeat enough.  Never, ever take credit for other people’s work (even if you helped out), and when in doubt err on the side of taking too little (preferably way too little) credit.


14 Comments on “Taking Responsibility”

  1. Marty says:

    Alan, I think this is the best statement of the architects role I’ve ever seen. Lot’s has been written about the practice of “software architecture”, but I think you’ve hit the nail on the head particularly in the project management dimension. My best experiences as an architect have been in the role you describe, and I’m pleased and happy that our software comes out of that kind of environment.

  2. Matt Grommes says:

    While we don’t use PolicyCenter, the fact that Guidewire has people like you on the team is one of the reasons I’m comfortable with my company using your other 2 products. Great stuff here Alan, you should be commended for your attitude.

  3. […] to a pointer from Kent Beck, I’ve just read Alan Keefer’s post, Taking Responsibility.  This is probably the best description I’ve ever read of the role that a software or system […]

  4. A great post! Thanks for writing this, Alan. (Thanks to Kent Beck for tweeting a pointer to it.)

    I’ve left comments at http://blog.gdinwiddie.com/2009/06/26/the-role-of-architect/ because they came out a bit long for writing here. As I said there, “This is probably the best description I’ve ever read of the role that a software or system architect should take.”

  5. Cary says:

    Alan,

    I think your analysis of responsibility and professionalism is spot on. If more engineering leaders/architects gave up the politically charged finger pointing and spent all that time and effort on taking responsibility and working toward improving the whole, that state of things in the software development workplace would be a lot better off.

  6. Doug says:

    Hear hear! This is the attitude I try to bring to every project. Why am I on perf (and have I been on perf for the last 4 releases)? Because it was evident that no one else was willing to commit to doing that work and the project would fail if it didn’t get done. I can hardly imagine the support burden we’d be dealing with if we had to react to some of the things we fixed during the perf effort. And taking a somewhat broader perspective, I’ve made a significant effort to reduce the pain involved in doing the perf work by sanding down some of the sharp edges, hopefully making this a more attractive prospect for others (and an easier job to do for all the teams). I encourage everyone to think beyond what you’re doing at the moment, and think about how you can improve the big picture, ensuring that the whole project succeeds. The more architects (in Alan’s responsibility taking sense) a project has, the better. And of course the fewer I’m in charge, let me push you around types (traditional architects) the better as well.

  7. Desfocado says:

    In my personal view, what you describe is the positioon of the project manager. Not just set the date and possibly take the credit, but mostly to be the umbrella for the working group.
    On the other hand I think that the model of distributed responsibility works better. In a social world where everybody puts in something, it is critical to know who did what and accept credit or fault for it. With project umbrella in place this should only be a constructive type of criticism.
    Thank you for a well written post.

  8. Phil says:

    I think that this is a good approach, but that it is taken a little bit too far. A leader of any sort has to take some blame for each failure of their team. However, they can’t afford to take so much that individuals lose accountability for their own performance, or that the leader’s own integrity is compromised. Sometimes it takes a dramatic failure to force the end of a dysfunctional relationship. A good leader has to recognize these situations and resist the temptation to enable the dysfunction to fester by heroically preventing the failure that it would otherwise cause. Another way a leader can take too much responsibility is when they associate their identity too closely with a project, often taking a zero-tolerance or failure-is-not-an-option stance. There’s no way one person can force a team to succeed, but there are an infinite number of ways they can mess up a team by trying. A leader (and everyone else, really) has to understand where their personal boundaries are and take full personal responsibility for all and only the things within those boundaries. After that they should take responsibility for other things in proportion to their potential to influence those things. It makes no sense to de-motivate someone by robbing them of accountability for their actions. It does make sense to fully explore the influence that you have over the things that you care about.

    I think that is what this blog post is getting at: an architect has far-reaching influence over an array of factors that affect the success of a project, and because of that they should be relentless about dedicating that influence to the service of as many of the issues plaguing a project as possible. But, there is an important distinction to be made between what one can do and what one should do.

  9. […] Taking Responsibility by Alan Keefer on the Guidewire […]

  10. Taras says:

    I agree with Desfocado, you are describing the role of project manager.

    As far as the responsibility goes, isn’t it one of the principles of Agile that the whole team is responsible for the outcome of the project, but the project manager is also accountable?

  11. Alan Keefer says:

    @Desfocado and Taras – Personally I kind of view this role as the responsibility of anyone in a position of leadership (including outside software companies). The more power you’re given to influence the outcome of X (and the project manager, team lead, and architect all have a lot of that power), the more responsibility you should assume for using that power. My personal rules of “management” are essentially 1) accept responsibility and blame, 2) deflect praise and credit, 3) hire good people that know what they’re doing and 4) get out of their way so they can do their job.

    @Phil – Thanks for the feedback. It’s probably worth some further clarification as to why my position is so extreme. First of all, psychologically I think it’s important not to give yourself an out; the prospect of failure, and of taking personal responsibility for it, is pretty daunting, and it’s natural to want to find ways out of that. So if the attitude is “I’ll make sure this doesn’t fail because of me” instead of just “I’ll make sure this doesn’t fail,” you have two ways to make that statement true: you can make sure it doesn’t fail, or you can make sure it’s not your fault. The latter is generally way, way easier, so it’s tempting to do, even subconsciously. So that’s why I personally prefer not to give myself that out, even if it’s a bit extreme.

    Secondly, this approach really only works if the project and team are reasonably functional. If you have good people who want to do good work and are individually going to take responsibility for their work anyway, then having someone in a position of leadership doing their best to assume any blame for anything that goes wrong helps avoid a culture of blame and blame avoidance. As soon as you start talking about holding people accountable and such, it quickly becomes in everyone’s best interest to not screw up, which means both not taking risks and, often, not doing much of anything at all. If the team is functioning reasonably healthily, people will take responsibility for their own actions anyway, and having someone else absorb the blame for them will just make them less stressed and more willing to make the right decisions even when they’re risky.

    But definitely, the last thing you want to be is the hero on a doomed project that prevents everyone from realizing how bad things are or doing anything about them. I think the proper response in that situation is to get out; if you don’t have the power to pull the proper levers (fixing tech debt, changing the architecture, adding or removing people, adjusting deadlines, adjusting scope, changing process, etc.) to fix things, then you can’t be held or hold yourself responsible for your inability to fix things. If you ask for and are given that kind of authority, though, it’s your reponsibility to take it, make use of it, and be responsible for whatever happens.

  12. Galen says:

    Alan – seems like you’ve just described the difference between responsibility and accountability: You can’t delegate accountability.

    Managers (certainly the good ones) are accountable. Responsibility is also a necessity by any other name – ownership, commitment, etc – but accountability is a condition sine non qua for successful management.

  13. Minh Vu says:

    This is the right philosophy because the man behind it live up to it. Because people are led by example, so whatever philosophy a leader pursuit, it will works if and only if the leader himself is an example. This is true for Alan, Adolf Hitler and Dr. King 🙂 even their philosophy are different.

    In my own little world and narrow view, I think that leader should be tough with his followers, demand nothing but the best from them, but taking the least when things go right and the most when things go wrong. The great leader should take himself out of the equation of what best for the company. Actively prepare his successors to take his place in case he’s out. He himself is nothing but the catalyst for a great company and transform himself into the cooperate culture. Alan is great, the and what better is we’re not done with him yet, we can get more from him.

  14. Manvendra Kumar says:

    A very inspiring blog, Alan. These are the real traits of great leaders and I believe it applies not only to Architects but to everyone as lead in any shape or form.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s