Getting Ready for a Cold Start

Alex Oleinikov

Software Engineering Manager at People.ai



About a year ago, I started a team from scratch. It was a cold, greenfield start: no PM, no other people -- just me. There was a broad idea of a product area floating around, but no team to back it up. So it happened to be me to set everything in motion and get us a brand new team.

While my new responsibilities spanned over a great variety of activities -- from wearing a PM hat for a while and setting up a hiring pipeline -- some things were more foundational than the others. That meant coming up with the mission statement and technical vision, one for the management and the other for the people I would hire.

Actions taken

First and foremost, I had to secure buy-in from key stakeholders. To do that, I had to set the vision. Since most stakeholders were non-technical people, I developed a non-technical vision that included a mission statement and impact assessment. On the other hand, to bring people on the team, I had to develop a technical vision that would outline what exactly the team would be working on. Hiring people motivated to work on a specific set of problems requires a detailed technical strategy.

Compiling both documents consisted of multiple steps I had to undertake. To begin with, I had to collect all available information. I would talk to potential stakeholders or sponsors, teams to whom we would bring value, and subject matter experts, amassing all I could: thoughts, ideas, problems, wild guesses, etc. That would allow me to draft a couple of pages-long document that would state the problem and how it would be solved, formulate a value proposition, etc. Once completed, I would start socializing the document. Typically, it takes several iterations, each followed by generous feedback from the same stakeholders you talked to in the previous phase. After the final draft would be prepared, I would call a meeting to ensure accountability of key stakeholders.

I would repeat the same process with the technical strategy. I found it a bit easier as I could rely on my own expertise, but often I would still have to step outside of my comfort zone ank ask for help from domain experts in the company. Finalizing the foundational suite of documents that would distinctly define the mission and lay the plan for the first six months before people start to arrive is critical. Without that, it is hard to attract the right people, let alone secure any support within the organization.

In the end, I would have to staff my team. I pay particular attention to MOC (Mission, Objectives, and Competencies) when designing scorecards. Mission would define what we would need this person to do in the next six to twelve months (to build a solution for problem A), Objectives would specify concrete outcomes (drive certain KPIs), while Competencies would outline specific skills, knowledge, and experiences. MOCs should directly translate into hiring questions. I would, as before, solicit feedback from different people who could help me see the problem from multiple angles. Being precise would spare me from “looking for the best people out there” and allow me to set expectations and focus areas advance.

Lessons learned

  • Don’t communicate your ideas broadly before you are not absolutely certain what you want. It’s easy to lose momentum and constrict attention if your messages are not clear and well-founded.
  • Define a technical strategy and key technical ideas before you start hiring tech people. You will need to convince them that they should work with you, and the most persuasive tool at your disposal would be this document.
  • Socializing is king. This is how you will get all the best ideas embedded into your suite of documents. It can also help you overcome an idealistic view of the problem and transform it into something sustainable that the organization will adopt. As a result, you will not face any headwinds in the first couple of months of existence.
  • Start your hiring pipeline as soon as possible. The ramp-up time for a hiring pipeline is around eight weeks after you start sourcing, which gives you enough time to come up with the suite of documents.
  • The more you are aligned with the overall organization from the start, the less explaining you will have to do later. The sooner you answer all the questions, the easier it will be.

Be notified about next articles from Alex Oleinikov

Alex Oleinikov

Software Engineering Manager at People.ai

Leadership DevelopmentCommunicationOrganizational StrategyCulture DevelopmentEngineering ManagementPerformance MetricsLeadership TrainingMentorship ProgramsPerformance ReviewsFeedback Techniques

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up