Defending My Work

If you’ve been following along, you’ll know there’s already been something of a saga with a previous employee. Sadly, that saga is still playing out in respect of the work they were supposed to be doing, but I now have to. If you’ve ever been in the position of having to basically redo a whole heap of work that you thought your were done with, you’ll know exactly how I feel right now.

To say there’s a little internal resistance to picking everything back up again, would be something of an understatement.

Also, I don’t actually have time anyway. So there’s that.

Of course, since I manage my own time, the second point doesn’t really stand up to scrutiny. The question becomes something more like, what are my priorities and how can I rearrange my work so that I have some capacity to pick this other piece back up again.

Still… Something will likely have to give in the process.

Anyway, this post isn’t really about managing time or priorities. Though I do certainly have some thoughts on how to do both of those things, they’ll have to wait for another post. Instead, this post stems from an incident earlier on in the week, where I was put in the position of having to defend my work.

At least, that’s what it felt like.

Defence Mode: On

Again, resulting from the departure of employee-X (as they shall henceforth be referred to on this blog), there were some discussions to be had about the current status of the related work and how to move ahead with it. Since I can’t go into detail about the specifics, you’ll just have to imagine the situation a little bit.

The piece of work in question is the design(s) for a completely new product. I started working on the design around 6 months ago, and then 3 months in I was informed that employee-X was available to help out and had experience with the architecture in which our new product was going to reside.

“Perfect!” says I, since I have have plenty of other work to be doing with our existing product portfolio. “Here’s all the work I’ve already done on this project, the specifications, the wireframes, supporting info (mind maps) etc. Please take the work I already did and refine it, build on it and have the finished artefact ready ASAP.”

Well… That never really panned out. Instead it transpired that after around 2 months of gradually degenerating output, nothing further got done. And now a further couple of months down the line, people are starting to question the original premises on which all of the work was done in the first instance. Which kinda bugs me, since during the time I was working on the project, plenty of other folk were involved (designers, testers, architects) who had input into the design and direction of the product.

And during that initial design & development period, decisions were made with a degree of context, including available data at the time of making those decisions (market data, competitive analysis, survey results), in good faith with everybody involved in the process.

Now, fast-forward 5-6months, and I have questions being asked about why those decisions were made, and whether they’re the right decisions and maybe we should do it this way instead, by person(s) without any of the preceding context.

This is a little tough to swallow. Which brings me to the key points…

Impartial input is good

The person providing this input is impartial. The fact that they don’t have any of the context preceding this point is arguably a good thing. They’re able to provide an objective perspective on the product design since they are not really involved in the project and don’t have to deal with the implications of any recommended changes.

I am partial. I am invested. I am the one who is likely going to pickup the majority of the work resulting from any recommended changes. With this in mind, it becomes increasingly difficult for me to see the wood for the trees, as it were. There is a sunk cost bias. I have already spent a considerable amount of time and energy on the existing designs & work, and I don’t want to lose, or sink, the cost associated with that work.

Being able to throw away some amount of design effort is an essential part of the creative process, however. The challenge is not to get so invested in the work you’ve already done that you end up resisting the need to rework it.

Ego is bad

Having some skin in the game is an essential part of any design activity, in my view. It would be impossible to come up with design artefacts that you would be willing to take forward and start developing with or turn into a complete product, without being or becoming in some way invested in them at an emotional level. After all, if the designs aren’t satisfying to you, why would you want anyone else to work with them?

Problems start to arise when you become so wrapped up in those designs that you think they’re the only ones that will work. Or that you know better than other members of the team. Or that you know better than the customer. Of course, there are many examples of designers who did know better than their customers what they wanted. Steve Jobs and Henry Ford being classic examples. But this isn’t one of those situations. I’m no Steve Jobs or Henry Ford. I’m a rookie Product Manager still learning his craft.

Look for the silver lining

The thing with this whole situation is, it’s somewhat painful. Having gone through so much time and having put in an awful lot of effort up-front… To have to revisit, reopen and redo a lot of that work – hurts. But there is a silver lining.

The additional and impartial input will likely result in changes that produce a better overall design and hopefully a better product. With some distance from the original work, and with some time having passed since doing that work – there is a strong likelihood that I will also see issues and opportunities for improvement. So, I’m treating all of the additional discussions and insights as little nuggets of gold that are going to help turn our product into something special and valuable to the customers who will hopefully be using it in due course.

Learning to let go of my ego has been a valuable lesson generally in my relatively short time as a product manager. I wrote last week about how I’ve tried to address this a little in some of the meetings I facilitate. Hopefully this more recent experience will solidify the learning and make me a better designer overall.

Opportunities to learn

There are other opportunities for learning and development that I’ll be capitalising on also. Since one thing we’re lacking at the moment is a good source of technical input for the product design, it’s an opportunity for me to learn some more about the framework and architectural issues myself. And, the feedback loop serves to highlight challenges in our delivery process, which is resulting in some helpful conversations about how to address them from a resourcing (i.e. people) perspective.

The overall delivery process warrants some attention also though, and since that’s an area of interest to me, there’s an opportunity for learning here also.

Thanks for reading. Feel free to reach out via a comment or on the socials if anything resonates.


One Comment

  • Robert Day says:

    Sometimes, it takes the presence of an Employee X to throw issues into sharp relief that were previously hidden because of others’ investment in a project.

    I know: I was once that employee.

    I started working in social security in 1980; not a direct entrant from school, but someone with a bit of experience in clerical processes and in public-facing roles. In those days, the whole process was mainly manual, from an initial interview to open a benefits claim, through calculation of entitlements, to the final stage of generating payments which only at that point were input to mainframe computers to generate ongoing payments subject to the claimant meeting certain conditions.

    When I was stationed at my new local office, I started on the same day as another new entrant who was straight out of school. We were both given the same 13-week training period and after that allocated to our specific duties,. Because my fellow new starter was only sixteen years old and I was in my early twenties, Departmental rules meant that he was not to be allocated to the public-facing counter section but instead put on the “boxes”, the back-office teams who dealt with routine work on benefits – renewals, changes of circumstances and repeat claims. The “box” teams were not generally public-facing.

    In contrast, I was put straight onto the “counter section”, doing face-to-face interviews and staffing the reception desk, which dealt with every sort of query from whoever came through the door for whatever reason. All new first claims were taken on the counter by personal interview. Counter work was generally given to experienced individuals with a particular mindset; I was neither of these things, but I was parachuted in to fill a particular gap at a particular time.

    After three months, it became clear that I was struggling. The expectation was that we would be able to interview eight claimants per day, and have their cases assessed sufficiently quickly to prevent any backlog building up. Sometimes, however, this wasn’t possible because claimants had to present certain documents in support of their claims – final wage slips, proof of savings, rent books rates bills and so on. If these weren’t available, we had to go through a number of steps to try to get this information verified, from asking the claimant to send this information in to actually doing a certain amount of legwork to get it ourselves.

    After a further three months, it was unavoidably obvious that I could not cope. My backlog of cases awaiting assessment was three times that of my colleagues’. I was at risk of failing my probation period. Fortunately, one of the section supervisors on the boxes had already got an opinion of me and my work and intervened to give me an extension, moving me to one of the other sections of the office. A colleague was rotated onto the counter sectio9n and I started dealing with more routine work.

    Within two weeks, everyone on the counter section had backlogs like the one I’d had. What no-one had realised was that we were on the leading edge of the recession of the 1980s when unemployment peaked at around 3.5 million. As a new and inexperienced member of staff, I’d simply been a harbinger of what was to come and I didn’t have the skills or personal resources to cope with a workload that was rapidly ramping up. My more experienced colleagues were coping better than I was, but in time even they came under the increasing pressure of the mounting workload. I was just the early indicator of the problems lying in wait.

    When my fellow starter hit his 18th birthday, he was transferred to the counter section where he relished and enjoyed the work. I was far happier in a back-office situation and did good work in a number of roles before after five years I took a transfer to the regional office in Birmingham and my life changed in very many ways – but that’s another story.

Leave a Reply