Finding a win-win when you don’t get what you expect from your developer

Eric and I sat in our one-on-one meeting, discussing his project.

”Do you think we can reuse Matt’s graphing code from the Find-a-Store project in your project, Eric?”

”Yeah, sure.”

”Okay, great. That should save us a lot of time. Matt is available to answer questions if you run into problems. Don’t hesitate to reach out to him, okay?

”Okay, I will.”

“Thanks, Eric. What do you have planned this weekend…?”

The meeting wrapped up, and Eric and I went back to work. The Find-a-Store graphing library was a big investment for the department, and I was excited we’d get to reuse it. My boss was concerned at the investment of creating this reusable library, but Matt and I had convinced her the extra effort was worth it. I was looking forward to reporting back that the investment was already paying back dividends.

Fast forward a week, and I was reviewing the code for Eric’s project. I was surprised to see he hadn’t used the graphing library. Actually, I was upset when I realized it. Instead of using the library, he’d written a new function that did only what he needed. It worked fine, but I was really frustrated. I’d gone out of my way to discuss reusing the library with him, and mentioned to my boss that she could expect to see our investment paying off soon.

As petty as this sounds, I wasn’t glad that his code worked, or that the project could be shipped to the customer.

I was irritated that Eric hadn’t talked to me before changing direction. I felt intentionally left out of the loop.

I ask Eric to stop by. When he sat down, I asked: “Eric, we agreed you’d use Matt’s graphing library. Why didn’t you use it in this project?”

“I dunno, it was simpler to just write what I needed.”

“But Matt’s library was finished, and was going to be a base for our new UI projects. We invested in it because it could be reused.”

“Well, you can reuse it with the next project. This projects one’s done, and I’ve already moved on to the next one.”

Frowning, I paused. “Eric, why didn’t you talk to me before you decided not to use it?”

“Look, we’ve got a lot to do, right? You’re always talking about how we should use our best judgement, and how much control we have over our work. I used my best judgement, and decided not to use his library. What do you want me to do?”

Sitting back, I wasn’t sure what to do.

Think about what you really want

I was conflicted. I was disappointed that the project hadn’t used the new library, and I was frustrated that Eric hadn’t talked to me about it when he decided not to use it. I would have liked to be a part of the decision, but now I only had the results of the decision.

But, maybe I was being too picky. He had finished the project in-budget and on-time, and it appeared to work as required. Was I micromanaging him?

And I was wondering the investment in Matt’s library was a good one. The whole reason we’d taken the extra time to polish and document the graphing library was so it could be used on other projects, but maybe that wasn’t necessary. In the past we’d had developers get stuck creating one- off graphs, and found each developer’s graph design was different. We wanted a common UI, so creating a library seemed like a good idea.

At that moment, I wasn’t sure if I should:

1. Accept the code and apologize to Eric for questioning his judgement.
2. Accept the code “just this once”, but ask Eric to include me in the decision next time.
3. Reject the code and ask Eric to re-work his project using the new library.
4. Accept the code, put Eric on another project, and have someone else re-work the project (or do it myself).
5. Discuss with Eric why he’d not discussed the decision with me, and try and understand if it was a sign of a deeper problem.

If I accepted the code, I was sending Eric the clear message that he’d “won”. Rejecting the code felt like punishment, making him feel he’d “lost”. What I needed was a win-win.

Looking for the right solution

Eric could see I was frustrated. I asked him to give me a few minutes to think, and told him we’d regroup after lunch. I told him I wasn’t angry, but he could tell I wasn’t happy either. He probably left feeling on-edge, like we all may when our boss is upset. While it might not seem fair to make Eric wait until after lunch to discuss it, I’m a slow thinker, and needed some time to process the situation.

As I reviewed my options, I saw each of them as a win-lose variation. What I wanted was a win-win solution. In my mind, a win-win solution would:

1. Improve (or repair) the trust relationship I had with Eric
2. Provide me with context about why his decision made sense in light of the project constraints and goals
3. Provide him with context about why this decision was important to me
4. Provide both of us with a common starting point to collaborate on a good decision

A closed door gives as many options as an open one.

In this case, I saw the win-lose options as “closed doors”. Those were pathways I didn’t want to take. But, I didn’t see the win-win solution. My goal was to find it.

Starting with a conversation

The older I get, the more often I see a conversation as the first step toward solving problems. Eric and I needed to have a conversation where we traded viewpoints, talked about project goals, and came to a consensus about how to move forward. I suspected that any decision we agreed on would be a win-win, and one I could take to my boss if necessary.

Having that conversation meant I needed to shed myself of some assumptions and be willing to talk honestly. If you’re going to ask for honesty, you need to go first.

• My first assumption was that Eric had been “silently resistant” to using the library.
• My second assumption was that Eric had a secret agenda, such as wanting to build his own library, not liking other developers code, or thinking Matt was an idiot.
• My third assumption was that Eric had hidden the decision from me until it was too late to change.

As I wrote them down, something became clear to me. Each of my assumptions about the reason for Eric’s behavior was negative . I had no positive assumptions about the situation, such as “Eric cared so much about the project deadline that he lovingly hand-rolled the perfect solution.”

My negative assumptions were going to color the conversation, and may make finding a win-win solution difficult. Seeing the assumptions on paper, I realized they were all fears driven by my insecurities, and I had no facts to back them up. I decided to adopt Stephen Covey’s motto, “Seek first to understand”, so I crumpled the paper and tossed it in the trash. I would do my best to listen to Eric’s reasons without bring my preconceived assumptions to the discussion.

Collaborating on a win-win

After lunch Eric came back into my office.

“Eric, my goal is for us to understand the other persons perspective, and decide together how to move forward. Could you tell me more about the decision to create your own graphing function, rather than reuse Matt’s?”

Listening, I wrote notes. I didn’t interrupt, but when he paused asked clarifying questions. I really wanted to understand the technical, project and human perspectives surrounding the situation.

His perspective became clearer. He admitted that he thought of talking with me, but figured that I was always busy, and that forgiveness was easier than permission. He didn’t have a problem with Matt or the library, but it didn’t exactly do what he needed. This meant he’d either have to make the library changes himself, or he’d have to create a ticket so Matt would do it. Either way, his project would be delayed. He didn’t think what he needed was that complicated, and it only took him a couple days to build something that worked for his project.

I learned a lot by listening to Eric, and I empathized with him.

When Eric was done, I put my pencil down. “Thanks for sharing so honestly, Eric. Next, let me give you my perspective on the situation.”

I explained how I’d hoped the graphing library would let us build nice UI’s faster, than I’d stuck my neck out with my boss to sell her on the investment, and how we’d built decent documentation around it to make it easier to use. I also explained how much I was looking forward to Eric using the library, to prove to myself (and my boss) that building it was a good idea. I admitted that these non-technical, political reasons were part of the reason I was upset by his decision.

I also told Eric about the seven other one-off graphing functions that we had in production, and our hopes that Matt’s library would replace all of them. Our goal was to make everyone’s job easier, and create a consistent user interface. I talked about my own surprise that he didn’t come talk to me during the project so we could discuss it, and how that made me wonder what other important conversations we weren’t having.

I finished up, and Eric asked a few questions. He didn’t like that I was letting politics affect technical decisions. He was upset that I questioned his judgement, and that he’d not been informed of the strategy surrounding the graphing library. He felt this whole situation was very stressful, and I agreed with him. Both of us sat in silence for a few moments.

Two possible win-win options

Option 1

“Eric, let me throw out an idea. I don’t want yet another graphing library in production, but I see where the one we have fell short. I also see that it’s a blocker to delivering the story this sprint. If I remove the time pressure on this story, what ideas would you have that would satisfy us both?”

“Writing the graphing function showed me exactly what I need for this story, and Matt’s code might not have been quite as far off as I thought. I could enhance his library to do what I need by adding a Z-Axis parameter and a LineThickness parameter to the LineChart graph. That way I’d also get to know the library so I could make edits to it in the future.”

“That would be great. I’ll run interference with the PO to let them know we won’t have this feature this sprint, but we should have it for the next one. Also, we can have the intern update the library documentation based on your changes, which will be good experience for him.”

Option 2

“Eric, let me throw out an idea. I don’t want yet another graphing library in production, but I see where the one we have fell short. I also see that it’s a blocker to delivering the story this sprint. If I remove the time pressure on this story, what ideas would you have that would satisfy us both?”

“Well, Matt’s library is used to graph 2D charts, and this project requires 3D graphs. I don’t think it makes sense for me to update his library now just for this project, as we don’t do very many 3D graphs.”

“Yeah, I see that. What about making your library a bit more generic, and writing some documentation, so we can use it for our future 3D graph purposes?”

“Oh, sure, that makes sense to me. Should we create a new ticket for that?”

I said, “If can be done this sprint, lets make it part of this ticket. Then I’d like to do a lunch-and-learn meeting where you and Matt present your libraries and everyone understands how to use them.”

Conclusion

Both scenarios were examples of a win-win, even though they had very different outcomes. Setting aside my assumptions, taking time to think, and identifying attributes of a win-win solution were key to a productive outcome.

Both Eric and I wholeheartedly agreed to the decision. There was give-and-take, and both of us avoided humiliation. More importantly, trust was rebuilt, lines of communication were opened, and a pool of shared context was created between us. In future one-on-one meetings Eric and I would build on this discussion, checking that we were “on the same page” as much as possible. We both appreciated that the situation had been stressful, and we agreed to try and avoid it in the future.

From this, trust was built between us. For me, that was the real win-win.

Finding a win-win when you don’t get what you expect from your developer was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.