In my current role at Helpshift, I’m the engineering manager of the Machine Learning Engineering team (“MLE”).
I’ve written this document to provide clarity to my team members on how we can work together.
This is not an essay. This is the practical day-to-day process we will be doing.
This is not about individual projects. We will discuss those separately when a project starts. This is about everything else that matters during your time here at Helpshift.
Some of the topics you can look forward to are:
- What work does our team do?
- What is my job?
- What are my values?
- How will we set goals?
- What’s my take on meetings?
- Slack or email?
- When can we talk? (1:1s)
- How do we work with other teams?
- What are my quirks?
Why write this document?
I have been an individual contributor (“IC”) software engineer for 12+ years. With every boss, there are unwritten rules and unwritten expectations. The best bosses are clear in their expectations and their feedback. I’m sure you will recognize this when you think about the best managers you have had!
When I came across a Manager README document written by Oren Ellenbogen (editor of Software Leadership Weekly mailing list), I fell in love with the idea. Of course, it plays right into my “write things down” obsessive nature. But more than that, it is a perfect vehicle to give thought to, find gaps, and to crystallize my working style.
Here’s why I like the idea of a Manager README:
- You know what to expect from me
- I clearly state what I expect from you
- “Explicit is better than implicit” – Lack of clarity leads to disillusionment.
- Off track – You should question me whenever I am off-track and not adhering to my process and values that I’m stating here.
- On track – You should have clarity about my expectations, your career growth, feedback areas, and so on.
- Everybody needs a coach – I hope this convinces you there is value in having a manager.
- I can continuously update this document, to reflect lessons learned and feedback received from my teammates and peers.
Why is this outside the company wiki?
- Because this is my personal style of management. This is not company-mandated.
- Because it forces me to have conviction in what I’m stating here.
- Because folks who are interested in joining the team can know how I work even before joining. Hopefully, this gives them confidence and clarity.
What does MLE do?
Collectively, data science team (“DS”) & MLE work with the product managers (“PM”) to design, research, prototype, build, train, evaluate, deploy, operate and monitor data science-based products.
DS does primarily research and MLE does primarily production but the lines in-between are blurred – we work closely with each other starting from the research phase all the way till the end.
MLE team’s responsibilities are:
- Providing tools and engineering support to DS.
- Collaborate on research with DS, especially running experiments.
- Collaborate on product definition and evolution with PM.
- Delivery of our data science products (“SensAI”) into production.
- Collaborate with the broader Helpshift engineering teams – core team, ops team, architects team, and data platform team to ensure successful integration of SensAI products with the broader platform, and successful operation of SensAI products.
- Working with customer success and sales to ensure our customers are successful with our SensAI products.
- Improving the engineering foundations to make DS & MLE more productive.
To understand more broadly on what machine-learning engineers do, see:
- What are machine learning engineers?
- What machine learning engineers need to know
- Data engineers vs. data scientists
A machine learning engineer is someone who sits at the crossroads of data science and data engineering, and has proficiency in both data engineering and data science.
What is my job?
- You – My role is to ensure you are successful.
- Question for you – What is your definition of success?
- Our collective responsibility is that the customer is successful in their goals. ⇒ How do we do that? By providing quality products. ⇒ Who makes that? You. Your role is to design and deliver quality products. ⇒ When this happens, our company becomes successful.
- Simultaneously, my job is to make sure you are not bored.
- Culture – Building a company culture where people want to stay.
- What is culture?
- What is important (values)
- How we do things (process)
- What is culture?
- Information – gathering, abstraction, filtering, and delivery
- My teammates are heads-down working. I am heads-up coordinating within our team and across the company.
- I work with other teams (product, data science, customer success, sales, operations, HR, etc.) to make sure we are aligned with the rest of the company and they are with us. See Communication below.
- Business Understanding – Talking to business stakeholders, leadership team, bosses
- During these discussions, we will collectively decide what are the right priorities.
- People management
- My teammates debug software. I debug people & process, so that my team consistently deliver high-quality work.
- Career development
- Having strategic conversations that lead to tactical conversations.
- Let’s discuss what you want to achieve in your career and how we can facilitate those steps here at Helpshift.
- Let’s discuss “what” you want (strategy) and then we can proceed to “how” (tactical).
- Of course, there are limits to what is possible because we have to balance your goals and company goals. I will work hard to ensure a good balance. When it is not possible, I will be direct in saying so.
- Remember, it starts with your goals – your intrinsic motivations.
- I expect my teammates to be mindful and direct about their purpose. I cannot decide that for you. ⇒ I often say “What does success look like, for you?”
- I consistently work to ensure autonomy and mastery for my teammates. ⇒ I often say “Are you set up for success?”
- Having strategic conversations that lead to tactical conversations.
- Leadership is a character trait. Management is a role.
- I expect all my teammates to behave as leaders.
- Leadership is creating an environment where everyone can contribute to solving the problem at hand.
- Project management
- Deliver projects on-time.
- Making best practices part of the process, so that they become habits.
- Technical Skills
- My role is a mix of engineering manager and engineering lead, but my approach is that we will collectively decide on how to build things.
- I will put people & process before writing code.
What do my bosses expect of me?
Company leadership, in general, expect me to deliver and increase my team’s capacity to deliver. (This idea comes from Michael Montano, VP of Engineering, Twitter).
How do we increase the team’s capacity to deliver? By achieving the high standards of values and communication I talk about below.
These are attributes of working style that I admire greatly and value in a colleague and in a team.
I do not expect you to have all of these values on day one.
I do expect you and I to look back every quarter to see that we both have made progress on these.
I expect you and I to be:
- Be conscious, aware and deliberate in our behavior and in our work.
- Be constantly looking for ways to improve as a team and improve our process (how we do things).
- Show compassion for others.
- Be self-motivated. We should only need to give guidance to each other, not push each other to perform.
- Design your own goals based on the agreed-upon team goals and proactively sign up for chunks of the team goals.
- Design long-term ambitions about your work and team
- When you disagree with something, push back, but respectfully.
- Show care about our work, be detail-oriented and always be on top of tying up loose ends.
- Be proactive regarding our tasks.
- Be proactive regarding cross-team coordination.
- Also see Communication below.
- Have conversations, with timelines attached.
- Don’t just “Let’s discuss”.
- Do mention effort estimates, dependencies and their ETAs, roadblocks, integration testing estimates, ETAs, internal dates, customer-facing dates, etc.
- Balance features vs. schedule vs. quality
- Avoid bikeshedding
- Ensure teammates feel safe.
- Be conscious that we are all in this together, working towards a common goal. We need each other to build successful products and a successful company.
- It is impossible to over-communicate! (See “Communication is the hardest thing in our careers” below).
- Setting High Standards
- If we are seeking rewarding challenges and wanting to do our best work, it only happens when we set high standards.
- Engaging in Life-long Learning
- Don’t be afraid of or averse to learning new things.
- I encourage you to attend and propose talks for relevant conferences.
Question for you – What are your values?
Communication is the hardest thing in our careers. Being proactive is the solution.
I often say “If it’s a problem, it’s always a people problem.”
Most of our frustrations and issues are because of lack of clear communication.
We cannot leave that work to “others”. We are both part of the problem and part of the solution.
We must proactively reach out to our colleagues to move things forward.
We have to work hard to make sure we don’t fail at our commitments because of communication gaps.
How does reducing communication gaps help? ⇒ we understand each other well ⇒ we are more clear about the work to be done ⇒ we make progress faster ⇒ we can be more successful as individuals, as a team and as a company.
What do I expect of colleagues outside of my team?
I would request our colleagues to:
- Understand that we are setting high standards here.
- Be direct in their feedback whenever our behavior is not matching up to these high standards.
- Collaborate with us in delivering high-quality products.
- Have fun together!
I do not expect our colleagues to follow the processes mentioned in this document. This is only meant for our team as this is my working style. Of course, our colleagues are free to adopt processes that they like!
- Interruptions – I want us to be mindful about maker time vs. manager time. Creative people (such as engineers and data scientists) need large chunks of uninterrupted time to do their best work.
- Remote – We are a remote and distributed team. Even if we weren’t, somebody (maybe you!) may be working from home. So, just assume this to be true.
- Hence, I believe our default mode should be asynchronous sharing, not synchronous.
- Because this gives time for the other person to give a thoughtful response.
- Because this gives time for the other person to do their core work.
- Our company culture prefers Slack. However, it is okay to shut down Slack if you are doing a chunk of work and don’t want to be disturbed. Do balance it with checking Slack every few hours (during working hours) and just before meetings (for any coordination).
- Our default mode of communication should be to use indirect ways of updating each other as much as possible
- Use JIRA for progress or roadblocks on concrete tasks.
- Use email for work discussions. Not Slack.
- I expect us to check email (and respond) once every 24 hours, on weekdays. Not more often than that.
- Use Slack mainly for time-sensitive work communication.
- Why? Because we need to find a calmer way to work
- You are welcome to use Slack and Zoom for casual direct chat though!
- Why meetings are important – because we are a team
- “The shortest way I can say this is that the most important thing in growing a company or team is to of course focus on getting things done, but the only way to get the right things done is by having meetings, by talking. There is no doubt that a group of people not meeting will get a lot of stuff done. It can be said with equal confidence, however, that by not meeting the stuff that will get done will lack cohesiveness, quality, and a shared set of values — the wrong stuff. The most expensive thing a growing company can do is get the wrong stuff done. This risk is magnified the larger the team, but clearly starts with just a couple of people. The question is how to get the right stuff done. The answer is by talking, listening, and discussing. Those together are the ingredients for a shared understanding and with a shared understanding the micro-decisions that everyone makes every day whether writing code, creating positioning, deploying a build, designing an experience, and so on. Where meetings are generally misunderstood is that the effort to make them efficient, goal-oriented, and conclusive is exactly what shuts down discussion, causes people to think about what to say next rather than listen, and generally prevents collaboration.” — Steven Sinofsky
- “We tend to think of meetings themselves as the main event, when in reality meetings should be the practice sessions. Instead of thinking about meetings as the regular season, think of meetings as practice drills or warm-ups. The real main event comes when you’re actually committing work to the screen. If you have done enough drills with your teammates then there’s a really good chance you know how they will react, how they can help, and how the work you’re committing will impact the overall “game”.” — Steven Sinofsky
- Regular Meetings
- We will have a weekly team meeting (early in the week), where I try to focus on strategic conversations, and focus on alignment.
- We will have regular 1:1 conversations. See below.
- We will have regular one-to-one conversations once a week, for 30 min (with some buffer time).
- I expect these conversations to be bi-directional.
- See “Career development” above, esp. strategic conversations that lead to tactical conversations.
- I expect you to bring two strategic points of discussion for every session. It’s not about putting pressure on you, it’s about having real hard discussions, that is helpful to you for your career ambitions. At the end of the discussion, both you and I should have more clarity on what you want to achieve and what are the roadblocks.
- Feedback Areas – See Goal Setting below
Dealing with Frustrations
I have stressed on communication above, so I expect you to talk to me, in a direct manner, about what is frustrating. Let’s work on it together.
Outside of that, keep in mind, that if things are perfect, we wouldn’t have a job 😉.
Our job is to improve the company, not only to write code.
Remember, we are measured by our impact, not by the number of projects or number of lines of code 😄.
I’m still working on this section.
I want to provide more actionable feedback by considering different feedback areas.
My current references are:
- Process (how we do things)
- Values (what is important)
- Medium growth ladder
- Patreon growth ladder
- Songkick growth ladder
- Meetup engineering roles
TODO I’m still working on this section.
- TODO Open Question: Should we build our own technology radar?
- Focus on improving technical foundations so that we have improve feature velocity (“how fast can we deliver a feature?”) for every new project.
- Focus on Code Reviews
- Focus on Instrumentation & Monitoring
- As an industry engineering culture, traditional emphasis is given to compile-time situation via code review, coding standards, linters, and so on. We should also give equal attention on run-time situation via monitoring tools.
Please bear with me:
- I’m still figuring out what is the value that I bring to this role (this document is a prime example). Am I a good manager or a case of the Peter Principle? Please tell me! 😅
- I’m paranoid about wasting your time and unintentional micromanagement – so I may err on the side of less meetings or less checking-in. Please tell me if you feel I should be more involved, I can definitely do that.
- I’m paranoid about “losing context”. Please regularly share the background of what you are working on, asynchronously (preferably JIRA, else Slack).
- I hate surprises. Please keep me informed about your observations within and outside the team.
- I love hearing others’ views. Please open up and talk to me!
- I love right priorities. I hate confusion.
- I love long-term thinking. I abhor short-term muddling.
- I believe in career craftsmanship.
Always remember: How can you, our team and our company be successful?
The only truly sustainable sources of competitive advantage I know of are:
- Learn faster than your competition.
- Empathize with customers more than your competition.
- Communicate more effectively than your competition.
- Be willing to fail more than your competition.
- Wait longer than your competition.
Everything else – intelligence, design, insight – gets smashed to pieces by competitors who are almost certainly as smart as you.
- Management overview
- Manager README
- Remote teams
- Management ideas