From Player to Pawn? One Engineer’s Perspective. (Part 1)

My company has recently started using Spotify’s Squad Health Check to track team health. One of the questions a team asks themselves is “Do you feel like a player or a pawn?” Recently I’ve been feeling much more like the latter of the two, but it hasn’t always been that way. Following are my thoughts on how in just a few months I went from feeling like a player on a team to little more than a cog in a machine. These are simply my feelings and opinions — it is not my intent to layout how I believe every team should work, but rather the way I like a team to work. I wouldn’t be surprised to learn that other engineers share some of my views though.

In order to understand what it means for me to feel like a “player” on a team let’s go back to a year ago and follow my journey from “player” to “pawn”.

The Mission

A year ago I had been working on one of my company’s products that required extensive use of a Workflow engine. I don’t need to go into details, but suffice it to say that the thing was a mess. Proposals would inexplicably get stuck in workflow with no way of knowing how it got that way or how to get it unstuck. Other proposals would somehow skip right through the remaining workflow steps and go straight to a published state. Customers were frustrated and engineers baffled. It will come as no surprise then that when I was approached and asked to help the company’s Core Engineering team build out the new Workflow tool to replace the existing solution, it took no convincing for me to hop on board with enthusiasm for the task ahead. This leads me to my first conclusion:

1. For me it is important to understand and feel that what I’m working on is valuable and will have a major impact to the company or its customers.

The People

Not long after I started working towards getting the new Workflow to where it needed to be for my team’s product, I was asked to assist with a presentation on the upcoming Workflow tool at a company conference where many of that product’s customers were present. It sounds cheesy, but honestly during this presentation I looked into the faces of these people and thought I saw reflected there the frustrations of the past as well as the hope and anticipation of a better future. Talking with them inspired in me a desire to make that future a reality for them. I stood in front of them and expressed my sorrow and sympathy for the challenges the old workflow engine had caused them and pledged that I would do everything in my power to ensure that the new Workflow engine would be an immensely more positive experience for them. I left that conference determined to make the Workflow tool everything these people wanted and needed. Second conclusion:

2. When I actually meet and talk with the people who will be using my work it humanizes them for me and I feel inspired to make them happy.

The Plan

Sometime around this same time period we were asked to perform a Gap Analysis between the product’s workflow needs and the existing functionality in the new Workflow engine. We started by holding a meeting with members of my team that were most involved with dealing with issues in our current workflow solution. This included the Implementation Manager, the Support Manager, the Product Manager, and myself. We brainstormed everything we could think of that our current workflow solution did or that had ever been suggested it could or should do. Nothing was off the table. Then over the course of the next several weeks we met with someone from each of our clients and allowed them to also share ideas on what they’d like to see from Workflow, while making it clear that this was brainstorming and not requirements gathering. I also showed each of them what their Workflow might look like in the new tool in order to give them an idea of what was coming, as well as an opportunity to offer feedback. In the end, we had a spreadsheet with hundreds of requirements that we had all discussed together.

The Product Manager, Implementation Manager, and I each gave what we thought was an appropriate priority to each of these requirements. The Product Manager took that information and separated the requirements into High, Medium, and Low priority buckets. It didn’t bother me one bit that the Product Manager had the “final say” in what was High, Medium, or Low because I felt like the decision was made with all of the relevant information and input. In the few instances that I disagreed with a prioritization, a respectful discussion usually followed in which we both left agreeing on an appropriate priority¹. After this exercise I was more invigorated than ever. I’d already had the motivation and now I had the direction — and more important — I felt like it was the right direction. Third conclusion:

3 It is important for me to feel like decisions on direction are made based on information gathered from all involved parties — particularly customers, engineers, and UX (User Experience) people.

Who makes the decision is not as important to me as how the decision is reached. This doesn’t mean I believe in decision by committee, but I do believe that in almost every case, everyone involved should understand why a decision is being made. In those cases where the person who makes the final decision goes against the suggestions of one or more of those involved, they should accept accountability for the consequences of that decision and everyone should commit to doing everything they can to make the decision work, even if they don’t agree with it.

The Journey

With the requirements broken into priority buckets we then organized them into two week sprints based on prerequisites and logical order. We did high level estimates and I was on my way. I found this incredibly motivating because I knew not only what I should be working on this week, but every week right up until the project deadline. Of course the plan changed over time — we moved things forward or backward in priority or even dropped them completely but the changes felt natural and logical and never happened without some sort of group discussion ahead of time. During this time period I was specifically asked by a fellow engineer — “don’t you feel like our company wants engineers to be pawns rather than players?“ and I replied without hesitation “not at all — I totally feel like a player.”

I think it’s also useful to note that when later attempting to describe to others how happy I was during this period I told them “I was just doin’ my thing” which I think may have mistakenly conveyed the message that I was “off in the weeds working on whatever I felt like without any collaboration or oversight.” While it may seem that I had an abnormal level of autonomy and minimal supervision during this time period, I made sure to report in Slack every day what I was currently working on so that anyone interested could be aware of what was going on². I also kept the status of the JIRA tickets associated with my work up to date and added new JIRA tickets when necessary (informing the PM when doing so). When major technical decisions were needed I would consult the other engineer assigned to the project and we never failed to come to a solution we both felt was appropriate. Halfway through this phase a “Core Workflow Collaboration” Slack channel was created where I would go to post product related issues that came up in order to allow the PM’s from all affected teams to discuss and come together to an appropriate decision. Thus I think the more appropriate description of this period would be that I was “working autonomously within agreed upon requirements and spontaneously collaborating with interested parties when necessary.”

These were without question my happiest days at my company. Rarely in my career have I felt so motivated, engaged, and inspired to give my very best work. I was excited every day to come into the office and work harder and smarter. Fourth and final conclusion:

4 Autonomy and trust are essential for me to feel happy and motivated in my work.³

I need to feel like I have the freedom to make decisions and solve problems within the guidelines of the agreed requirements.

To recap the 4 things that inspired and motivated me during this period:

1. The feeling that what I’m working on is important and impactful
2. Meeting and talking with the people who my work will help
3. Decisions being made openly based off information gathered from and visible to all involved parties.
4. A sense of freedom and autonomy to solve problems and make decisions within requirements.

In the next article I’ll discuss how in a short span of time I went from being inspired and motivated to feeling frustrated and “stuck”.

Footnotes:

1 There was one major exception to this statement which I’ll get to later — the “Simple UI”

2 It should be noted that my daily updates were posted to a channel private to my team and therefore there may have been people who felt like they had no idea what I was doing. However, I believe that my PM was communicating and coordinating with other PMs and management as necessary.

3 It turns out I’m not alone in this regard. See https://facilethings.com/blog/en/pillars-of-motivation