Growing in an Early-Stage Team at Talkdesk
Lessons learned from growing together with a team at a Forbes Cloud 100 company and Gartner market leader.
I couldn’t resist an old habit of mine: planning ahead. Before I even stepped into Talkdesk’s Lisbon office, I tried to predict all the problems and their possible solutions. However, because of my lack of experience in tech, and even less in having a job, I couldn’t have imagined what was to come.
One of the problems I didn’t foresee was this surprising meeting with two Talkdesk directors in my first week. I immediately thought: “did I make too much noise playing foosball with my internship fellows? Did I mishear and the snacks were not actually free?” Not exactly. “The team you’ve chosen in your form is going through some heavy work and is not in the stage of accepting junior engineers”, one director told me while glancing at the other director, who completed the sentence with: “but the good news is… I’m putting together a team to work on some challenging stuff. Miguel, are you in?”
I didn’t accept it right away. I had meticulously thought through which team I wanted to integrate as an intern. Nevertheless, there I was. Going off-script. So my first decision at this company was made the next morning. I was ready to accept the challenge and go with the flow.
Besides, the opportunity of starting my career on an early-stage team and being part of its culture brewing process enticed me, as I had been working on very challenging projects. Since the team foundation and project handover, we tripled project ownership in the first nine months while rocking our visibility. Yet, visibility was only the tip of the iceberg. Throughout this article, I will tell you what lies below and what are the major lessons I’ve learned on my journey so far.
Viewpoints
My first three months at Talkdesk were the first three of the team as well. At this point, we were a team of three developers: one senior engineer and two interns (including me). We had a senior product manager and an associate product manager leading the product. Also, we had the privilege of having our own Agile coach.
With this multidisciplinary team, one of the first things I’ve learned was to adapt my speech according to the meeting. I remember dwelling on technical matters while we were in product meetings such as high-level refinements and release estimations. Therefore, I came to learn three major viewpoints:
- Product: limits itself on what the stakeholder wants, combining with the vision of the product manager. This should be stripped of all the technical matters. It should be as straightforward as the completion of the following sentence:
As a __________ I want __________ so that __________ .
- Quality Assurance: focuses on what is sufficient to validate a given feature, also known as the acceptance criteria. The acceptance criteria description is not only about the output one user story creates, but also the actions that trigger that behavior.
- Development: focuses on what needs to be technically done to achieve the acceptance criteria, also known as the technical approach. This includes software architecture, technical dependencies, and problem modulation.
Each viewpoint is not meant to be empowered only by the person that is entitled to that job but by all the team members. As we all work towards the same goal, we need to ensure that Product, QA, and Development are aligned.
Therefore, in the refinement sessions, we easily adapt our viewpoint to facilitate the job of the others, so that everybody is comfortable with the current decisions and estimations. For instance, developers should make sure that the technical approach produces a clear output for QA to validate. Whereas Product may design the feature iterable enough to deliver value throughout minor codebase or architectural changes. This is only possible with open communication between disciplines.
Communicating across viewpoints does not happen only during a pre-development stage. Inside our team, the communication between disciplines is on from the creation of the user story all the way to going live in production. For example, when I’m developing a story, it’s very common to have a call with my product manager to align some product-related details that may arise. Similarly, when the feature goes into the QA phase, the assigned QA engineer communicates freely with the development and product team to make sure everything is right and ready for production.
All this communication goes by a very informal and agile form. This strips away all the bureaucracy and overhead that many software engineering teams struggle with when using other methodologies. Therefore, when a feature is deployed, there are no surprises as the product and technical visions have been synchronized throughout the lifetime of the initiative.
Vulnerability
Having trustful, transparent, and recurrent communication with my teammates is key to keeping a healthy professional life while maintaining sustainable high-performance and growth.
I’ve experienced it myself and I’ve been told that in many workplaces you don’t even have a recurrent 1:1 meeting with your manager. Not having those is like painting a picture keeping a 1 cm distance from the easel from start to finish. Having a 1:1 with my manager from time to time makes me dive into recap mode where I force myself to stop, zoom out, spot improvement areas, and, only then, understand new directions and goals.
On my team, each member keeps a schedule with a monthly 1:1 meeting with the manager. On top of this, we frequently have 1:1 meetings with each other. This means that one week I can meet with one of the team’s QA engineers, and the next week I can be discussing improvement points with another developer. I like to base these meetings on the following bi-directional topics:
- What do you think I’m doing well?
- What do you think I should improve?
- What do you think the team is doing well as a whole?
- What do you think the team should improve as a whole?
The conversation should not be an answer-to-the-questions-and-go, and much less an interview. It should be a collaborative workforce on how we can improve each other. Growing is not a solo mission. If you help to grow, the team grows, therefore it grows you, therefore it grows the team, and so on. Once you get into this vicious cycle, it becomes a beautiful feedback system. However, such a system needs to be constantly fed with vulnerability and trust.
Assertiveness
Effective communication is 20% what you know and 80% how you feel about what you know. — Jim Rohn
I knew very little about assertiveness when I walked into Talkdesk. Actually, I used to think that it was the quality of getting it right every time. I was wrong. Assertiveness is about how you express yourself to another person and it’s easier to understand it when you know what assertiveness is not.
Assertiveness is not about being aggressive when you present your ideas. You want to talk about how you feel and not about what someone or action is. For example, “actually, I feel like we should go with the PostgreSQL architecture because we are using many relations between data models for this project” and not “your architecture does not make sense at all, why would you want Cassandra for this problem?”. Got it? The first one is assertive, whether the second one is aggressive.
Assertiveness is also about not being passive. A passive posture is a submissive posture even if you disagree. When you think differently than what you hear, you should speak up. Don’t worry if it does not make sense at all. You need to shoot several times until you start to hit it with more accuracy. However, if you don’t know the subject well enough, make key questions, study the subject, prepare yourself better for the meetings, and/or book an induction with a teammate that can help you out.
I’ve seen people trying to be assertive and falling into the dark side of it: passive-aggressiveness. It goes undetected many times but it silently poisons the team over time. Passive-aggressiveness shows up when one acts indirectly aggressively, thus avoiding confrontation because apparently there was none. This goes from the repeated behavior of running late to the avoidance of 1:1 confrontation.
In short, assertiveness is about expressing what you feel by exposing it clearly, opportunely, and appropriately with the benevolent intention of approaching something, others, or yourself.
Time
Research has shown that children perceive time slower than adults. That would explain why it took me so long to reach the age of 18 and so little from then on.
In his book, The Effective Engineer, Edmond Lau, a former Google engineer and former CTO of Facebook, states: “high-leverage activities are the ones you want to focus on” so that you make the most of your limited time.
For one to increase the leverage of some activity, there are two options:
- Decrease the time invested. If you execute far too many times the same manual task, you should find a way to automate it or figure out some shortcuts.
- Increase the value produced. If you can’t complete a task faster, invest the majority of your time on what brings more value to the table. The Pareto Principle states that 80% of the value produced comes from 20% of the time invested.
It’s very common to see highly successful people giving talks and interviews about time management and it happens for a reason. In a famous roundtable with Bill Gates, hosted by Charlie Rose, billionaire investor Warren Buffett said: “time’s the only thing you can’t buy”. Consequently, managing it is the only thing you can do.
We all have said, “I don’t have time”. We all have the same 24 hours. It’s all about priorities. We don’t realize it, but when we say “I don’t have time”, we are actually saying “I’m not making that the first concern”. So, our frustration with time is actually a reminder that we need to review our priorities.
Perseverance
When it comes to mastering a specific skill, time becomes a requirement more than a liability.
When I started working in tech, two years ago, I felt like I should have certain skills as soon as possible and there was no time to waste. However, the only thing I got was unease from all of these big ambitious goals for the next day. Once I got tired of trying to anticipate those moments, those skills started to come naturally.
I came to the conclusion that it takes time for a seed to grow into something visible. Talent does not mean you were born already mastering a skill.
Proficiency comes with practice and from being exposed to many situations. Redirecting my effort into establishing smaller goals while being more patient on big immediate results has given me a more sustainable and healthier growth.
While I was in college, I used to imagine how it would be to run code in a real production environment. The more I read and went to conferences, the more I was excited to dive into the tech industry. From meeting wonderful people to learning so much, going off-script was not that bad. Stepping out of the comfort zone can be frightening, but it’s in its outskirts where major growth and learning happen.
