How I like to work as an IC

Fresh out of university in 2010, I was clueless about working in a professional environment while collaborating with more than one person. In the span of one month, I got introduced to Agile, Scrum and Jira. What tickets are, why they should be estimated, and that User Stories always start as “As a user…”. I did not have any frame of reference, so I swallowed it.

The agency

My first employer was operating as an agency, or outsourcing company. We had external clients that had a rough idea of what they wanted. As with any big client there was a lot of ambiguity. But more than that, as an IC (individual contributor), I had 3 layers between me and the end-user. I didn’t understand the user, why we are doing a particular feature or what’s the business value of my work. We were using Scrum and I found that the daily stand-ups were useful in this environment. They acted as a bridge between the outsourced team (us) and the client (via our own project manager). We were using Jira. The Project manager created tickets with enough detail and we estimated them. Scrum, and stand-ups in particular, were useful in this configuration. There were a lot of moving pieces with different agendas and motivations. This was my first and last experience in an agency model. I didn’t enjoy it back then, and I am quite confident I wouldn’t enjoy it now. I like the idea of continuous iteration and having skin in the game. In an agency, I didn’t feel I had. A project would finish and I would go to the next one. The circle of life.

The consultant

In my second role I was working as a consultant. In one of my first projects, besides being an IC, I was also technically managing another team 6h ahead of us in Beijing. We were again using Scrum. Stand-ups acted as a syncing point between everyone. For a second time I had no contact with the end-user, nor did I have access to the person for whom I was working for. I was squeezed between the code and a project manager. The project was small, but the team layout was challenging. Once the project was done I was moved to a new project. I didn’t feel it was much different than my initial experience in an agency. Being sometimes embedded in the client allowed me to understand them better, but I was still far from the end-user. I didn’t have access to a proper Product Manager, but rather a Project Manager using Gantt Charts as ammunition. It was not a particular fulfilling role.

The product team

After these two experiences, I found myself in product teams. Not necessarily squads, or cross-platform teams, but at least we had a Product Manager, an UI/UX designer and some backend firepower. Scrum continued to be used, with a brief exception where I would use Kanban. Things were different here and there, but they followed the same recipe:

  1. Typical ceremonies: Stand-ups, Sprint Plannings, Retros, Design Workshops.
  2. Sprint planning taking multiple hours (not uncommon to be more than two hours). Tickets were done as a group. Although only one person worked on it.
  3. Scrum Poker with non-technical people estimating technical work.
  4. Estimation work took hours, but no data was analysed. Are we going faster, slower? Are we getting better with our estimations? No one knows.
  5. People discussing unrelated topics during stand-ups. Stand-ups set for fifteen minutes would take close to one hour.
  6. Superficial retros, where deep interpersonal problems were not addressed. No action points were followed up.
  7. Async stand-ups on Slack. Where people blurb a couple of meaningless sentences.
  8. Sync stand-ups where people have the Jira board open and are reading ticket status.
  9. Tickets and the PM’s opinion as the source of truth.

In my last role as an IC, I got exposed to a different way of working. Product managers wrote a PRD (Product requirements document). In a single page, I could understand why we are doing something, who’s our end-user, what value we want to get from our work and what success looks like. This at the meta level. Further down, I could see the feature requirements, the acceptance criteria, testing scenarios and tracking. Technical decisions, architecture considerations and diagrams were added as child pages. A new joiner, in a couple of hours, could have a firm understanding of why, how and what the squad was working on. Good documentation, doesn’t need to be long. It needs to be clear and to the point. A well written paragraph is worth 10 tickets. This approach to work was a revelation to me. But it didn’t end here.

A good PRD, alongside a disciplined team using a tracking tool (we were using Linear), made stand-ups obsolete. If I want to know what a backend engineer was working on, I could filter by their name alongside what’s in progress. I could see what they would work next. Waiting for the next day to raise blockers was nonsense. If something serious happened that would prevent someone from working, we would mention the relevant people in Slack. The same approach was used for changes, or unexpected circumstances, that weren’t blocking, but deserved the team’s attention. Waiting 24h to sync communication is silly. There is no need to interrupt someone via Slack, or have a call, for a status report. Communication became push driven, instead of people pulling information from each other. Sometimes a video-call is the right tool. I remember having 10 - 15 minutes calls with team members, to clarify specific edge-cases. Rather than playing ping pong for an 1h in a Slack thread.

The sprint planning’s focus shifted. Engineers were already creating and estimating their own tickets. We all knew what we had to do based on the PRD. If I need to understand how the project is progressing I could check the Linear board. Sprint plannings were now used for the PM to provide further context, clarify edge cases and get a sense of how people were doing. During the sprint planning we would drag the tickets we felt comfortable we could deliver. There was some debate, but not the shenanigans I experienced in the past.

Some of the nonsense time I previously mentioned was now used in:

  1. 1:1 calls with my PM. We would discuss user-needs, UI delight (e.g. animations), tech. As a side effect our relationship was stronger.
  2. Interviewing end-users. I could see what they wanted and how excited they were when we mentioned a new feature.
  3. Socials with the whole team, to strengthen the relationship and create bounds.
  4. Close to 80% of my time was fully devoted to IC work:
    1. Writing code
    2. Reviewing code
    3. Reading and understanding my squad’s PRD
    4. Check on other squads PRDs.
    5. Reading other engineers RFCs
    6. Reading transcripts from user-interviews

What’s missing?

If I was reading this text a couple of years ago I would assume that, as long as you have great people on your team and a good PRD, everything works out. Unfortunately this is far from the truth. I have seen this as a manager with engineers in many squads. As an individual there’s nothing wrong, but for some reason things don’t gel as a team. There can be many underlying reasons, but the common culprit is the same: lack of trust. If you don’t trust the people you work with, all the things I have mentioned won’t work:

  1. Someone is taking too much time? They are probably slacking and I need to be on top of them.
  2. Stand-ups are not happening? How sure am I that the Jira board represents reality?
  3. PM missed a requirement? They are just clueless.
  4. I am seeing a mistake in a PR? Won’t say anything, otherwise they might take it personally.
  5. Does the Designer miss the error state? How is it even possible?
  6. This person created a bug in production. Time to have a chat with their manager.

High trust environments improve all the above. If you trust someone else and they do something poorly, you assume good intentions. You give them feedback and they are thankful for your openness. The relationship gets stronger and so does the team. It’s a self-reinforced loop. Environments that lack trust, can be superficial. Little value is yielded from retros, if they even happen. People don’t feel comfortable exposing their concerns to the team, so most members are lurkers, not active participants. People clamp up.

Building relationships earlier with your teammates is the best investment you can make. It will make challenging situations go smoother. It will allow your team to move faster and build great products. Even with a great PRD, company mission and exceptional individual talent, without trust you won’t go far. It can make a trivial project look like a monumental effort.