When To Hire More People

Congrats, you and your co-founder have found moderate success with validating your idea, but now you need people to help you execute your plan. Who should you hire to join your team and when is the right time to bring them onboard?

First thing to think about is where are your weaknesses currently, and what type of people can help you fill those gaps. Do you need a strong sales person? Or does your site need a UX designer? Maybe you need a developer? How about an admin to help you schedule?

Then, decide if you need this person immediately or if you can wait. Can current team members pick up the slack? If not, put up the job posting. If you can wait, but you know it’s not sustainable for more than a few weeks, start the search.

Finally, consider whether this is a short-term need and how much effort will be involved. If someone can redesign your site in a few weeks and then only be involved a few hours a week, hire a contractor. If you see this person as a key member of growing your organization, look for a full-time candidate that can evolve with you.

Side Note: When hiring someone to join your team in a W-2 capacity, make sure that you have enough work for them and enough money to pay them for at least 6 months. It’s unfair to promise anyone anything less than that and it’s also unreasonable for them to expect more than that from a startup.

Good Communication Practices

If the core skills needed to be a good product manager are prioritization and communication, then you better be a great communicator to get your priorities done right.

Communication is bidirectional, you must listen more than you speak. The inbound feedback is often more important than what comes out.

How do you gather good information?

Start by checking your ego at the door. Be open to hearing what people have to say, even if it disagrees with your perspectives. Genuinely listen to people, and let them finish their whole thoughts before asking follow up questions. When asking questions, make them open ended so that you get maximum amount of information.

Additionally, be sure to request information from a diverse group of people. Not only in the diverse ways defined by equal opportunity policies, but think about different roles and personas and how they can add to your understanding of how your product might get used.

Talk to your sales team about what they are saying to win customers, and have discussions with lost prospects about what you were missing. Listen to different sized companies in varied industries if you’re working on enterprise tools. By hearing various points of view you will learn more.

How do you provide good information?

Telling others what to do is an art more than a science, and you’ll have to find your own style. Keep these things in mind as a guide.

As a manager, you have to manage the team and bring the along with your vision. Strategies for doing that often involve meeting with key stakeholders one-on-one prior to larger presentations to get advance buy-in. Play to what your team values and emphasize how your plan fits in with their goals.

Also, be sure to provide the correct level of detail for your audience. When you supply highly specific information like a screenshot, it communicates to the team that you want it done that very particular way. If you talk more in broad strokes such as in quarterly goals, team members will feel more ownership in the decisions but it may not result in your precise vision.

Finally, whenever sharing information, remember to allow for feedback and questions from others in response. It will both help you know that your point was understood and allow you to clarify or adjust your message as needed.

How to work with developers

If you’re running a software company, and even if you aren’t, chances are you’ll be working with developers. How effectively and efficiently you are able to do so will extend your runway and let you sleep easier at night.

Developers are generally smart people who like to build things that solve problems. Understanding this basic generalization and keeping it in mind when working with them reminds you to respect their opinions and also to inspire them with what your goals are. When you start from a place of respecting your team, they are more prone to listen to you and work hard to achieve your vision.

Rules of thumb when giving developers instructions:

1. Pictures are worth 3000 words. Show, don’t tell them what you want. It will save you a lot of headache and allow them to ask questions and provide valuable feedback.

2. Explain the goal and expectations. When writing user stories or when describing something, be sure to include both what the end goal is (so that they can potentially suggest alternative routes) and the acceptance criteria (so that they know what you are expecting them to deliver).

3. Leave room for creativity. Make sure that when delivering instructions that you leave time for questions and suggestions. When your developers feel ownership of the final product, they will work harder and will often deliver more than you anticipated.

Even if you follow the three rules above, there will still be bugs and features that don’t work as expected. Be careful when reporting bugs and make sure that the software in fact used to work a certain way and now it does not. Provide steps to reproduce the error and what the expected result is.

If the feature is being built for the first time and doesn’t match your specifications, that is not a bug. It is an rejection of the feature and an opportunity to see where the communication broke down. Remember it may be the way you communicated your desires, not only how they were interpreted.

When you keep the items above in mind, you’ll have a better relationship with your development team and accomplish more together.

Have any tips to share?

How Slack Can Help Everyone STOP Saying “You Guys”

A year or so ago at a Justworks JustWomen event, I heard Kristy Wallace talk about how at

Ellevate Network

they have a Slackbot that responds anytime someone says “you guys” in a

Slack

channel. It is a small thing that nudges people in the direction to be mindful about their word choice and how it might be an indicator of unconscious bias and unintended feminine minimizing.

I decided recently to do the same at at my job. Here is the Slack instructions on how to do it yourself.

This post is not about the debate about whether or not you should stop saying “guys”… this is about how to do it yourself. I’ll leave that discussion to these publications:

The Problem With ‘Hey Guys’

‘Hi guys!’: what’s wrong with this greeting?

Why I’m finally convinced it's time to stop saying "you guys"

Step 1… from the drop down click “Customize Slack”

Step 2… from Customize Your Workspace the tabs click “Slackbot”

Step 3… click “Add new response”

Step 4… add multiple trigger phrases and auto responses

did you mean “everyone” or “team”? https://www.vox.com/2015/6/11/8761227/you-guys-sexism-language

did you mean “you all” or “all of you”? https://www.theatlantic.com/family/archive/2018/08/guys-gender-neutral/568231/

Step 5… click “Save response”… EASY right?

Step 6… wait and see what happens… as I am right now :)

Tech Debt for non-Tech People

If your product is anything more than a week old, there is Tech Debt. What is Tech Debt? How does it hurt your Product? What should you do about it?

Tech Debt is A-OK

Though Tech Debt may seem like the pot hole your team could at any moment stumble into, it’s a healthy part of the SLDC. Similar to have credit card debt in your personal life, it allows you to purchase larger ticket items as you wait for your paycheck to come in. Or it can be like student debt where you rack up a bunch of it while you are growing and once you are in a steady state you can start paying it back. In both cases, debt is required to get you where you want to go. The same goes for Tech Debt.

Tech Debt is the remnants of previous releases which make developing new features more tedious than it would be if you were starting from scratch (like a Tetris board). Don’t get mad that it exists, your engineering team was (hopefully) operating under whatever knowledge they had at the time of development and working with the best intentions of reaching the targets set for them. Remember that racking up tech debt is most common when there are deadlines set by product and corners are cut. You or your peers probably had a role in getting you to the current state, and you have to own that.

Though engineers claim to loathe tech debt and wish they could eliminate it, it is rarely the best idea to attempt to plan for all potential futures that are not well defined today. You will end up investing a lot of engineering time in things that may never happen. If you have a good idea on your direction down the line, share it with the development team so that they can keep it in the back of their heads as they architect the software. Don’t make it the primary focus, that should always be the customer or business value the team is working on right now.

SDTimes

When to “Pay Down” Tech Debt

Again with the credit card analogy, the phrase for getting rid of excess tech debt is to “pay it down”. Note that it’s not pay it off, as it is pretty near impossible to eliminate all tech debt, and isn’t worth the effort even if it was. But you don’t want to be drowning in tech debt anymore than you want to be haunted by high credit interest rates.

Engineers don’t love having what is referred to as spaghetti code or non-optimized code out there. Engineers are problem solvers. If the problem is tech debt, they will want to pay it down. They are the people who seemingly are most affected by the tech debt as when they are working on new features or bug fixes, it will take them longer to do what they need to do.

But Engineers are not the only teams impacted. Customers may experience a buggy experience, account managers may deal with churning clients, sales teams may have to wait longer for features that help close deals. Tech debt is felt throughout the organization in different ways, and therefore you as a product manager should prioritize paying it down, but when? Here are some options on how and when to pay down tech debt.

• Regular Refactoring: I describe this process as cleaning out the vegetable drawer from rotten veggies before you put fresh ones in. The rotten ones will in fact spoil the newly purchased ones. If you clean a little bit every time you open the drawer, it will often be maintained for a few months without any issues. Similarly, if you encourage the engineers to “leave the code better than they found it” as they add new features the code base will continuously get better. Be sure to timebox this effort (work with the engineering lead on what is appropriate), but know that similar to bug fixes this should be allocated as part of resource planning.

• Periodic Rearchitecting: Every so often your fridge needs a deep clean and the same goes with your code base. Maybe you now have dozens of transactional emails sent by the system and the team wants to consolidate them into templates. There could be a big initiative that the current architecture won’t support. Alternatively, your product may have performance issues that are causing churn or a certain part of your application is too buggy for customers to use. These are all good reasons to invest heavily in paying down a lot of tech debt.

• Platform Transitioning: Now your fridge is old, it’s time for a big upgrade. You have to figure out whether all needs to go, or that it just needs a new shelves, or that only the freezer is broken and you can buy a separate deep freeze. In tech, the situation is that you’ve built a solid product with monolithic architecture and are now changing your business strategy to become a platform, and there will be APIs which will be built to support the ecosystem. Those APIs can also be used internally as well and a big effort maybe required to transition the current application(s) to those APIs. As applications are changed to consume the APIs (which is a rearchitecture in it’s own right) additional optimizations will generally also be made. Be careful with building everything from scratch as you can generally segment out big or small chunks of functionality together similar to that separate freezer instead of throwing out everything.

When you’re considering doing something like a big architecture change, be sure to understand the full costs of the current situation and the potential benefits of a big change. Weigh the costs (including customer service time, lost deals, maintenance costs, wasted engineering time, etc.) against the potential benefits (new logos, faster customer onboarding/revenue recognition, ability to bring on partners, etc.) and make sure that the effort is a sound business decision. This is easier if you have solid Product Operations dashboards available, but estimating each of those drivers will be key to making the right decision. It will also help you scope the project to be “right-sized” and deliver maximum value.

Have you done a financial analysis and proven that the effort to pay down tech debt is worthwhile? That’s awesome! We’d love to hear about how you evaluated the cost and benefits, please share.

What it’s like to work at a company with a Values Based Culture

Some companies build great products but are horrible to work at, some have great culture and never get to product-market fit, and very few are wonderful places to spend most of your waking hours and also produce something happily used by millions of people.

Justworks is in the rare third category above. My first few months working here have been nothing short of amazing and inspiring. As I said to Isaac Oates, our CEO, on our Pride 2017 float… this is a very special company; I’ve met with over 100 companies since I moved to NYC four and a half years ago, and this is one of a kind.

Why am I so enamored with this company, it’s mission, and the team? It comes down to values. Buzzword alert! I know. But unlike many startups in Silicon Valley and Alley, the culture of Justworks is in fact the sort of thing that HBS case studies will be written about.

I will spend the next two dozen paragraphs listing all of the wonderful things our company does to encourage and reinforce the stated values. It might seem like I’m providing a recipe for anyone to follow. But, I believe that the level of intentionality it takes to create and sustain culture like that which you find at Justworks is even more rare than product-market fit. So read on to learn about some options to consider when trying to build and reinforce your core values into your culture.

Let me start by listing our values.

Compassion, Openness, Grit, Integrity, and Simple. Internally referred to as COGIS. Really, we say things like “That’s not COGIS, so let’s not do it.”

1. Compassion

Other companies may call this empathy, but compassion takes it to another level. Don’t only attempt to put yourself in someone else’s shoes, show them you care.

Not surprisingly, this value is best seen on our Customer Success team which sets goals for satisfaction levels that match the most loved consumer brands. To reinforce the importance of the targets, we celebrate positive customer feedback with a physical board where notes are pinned up and a Slack channel where comments are posted and shared. On the other side, we do in depth research into why customers churn and where their frustrations are to see how we can make it better for others.

But it goes so much further than customer success. So that all employees understand the value of what we do for customers, at least once a month at our weekly All Hands meeting, we bring in a customer for a fireside chat with a top exec. One or two representatives from a member company describe their business and how Justworks allows them to focus on their mission.

As a demonstration of compassion for not only customers, but coworkers, we make time for each other. Many specialty teams (Business Intelligence, Sales Operations, Front End Engineering, and more) set aside 2+ hours a week for “Office Hours”. This time is not for them to do their own work, but for other Justworkers to come and learn from them. We don’t want our co-workers to become frustrated because they can’t move forward on hard problems and we want them to be empowered to solve them independently in the future.

There’s a similar “Ambassador” program in the product/engineering organization. One elected member of each Pod (product specialty) makes themselves available to other teams. Rather than say “figure it out”, we say “let me help you understand.”

2. Openness

Radical transparency can be frightening for certain organizations. It often means that employee salaries are made public and that the executives share all the ongoing problems with everyone.

In reality, that rarely happens and that isn’t what being transparent is about at Justworks. It’s about being upfront with our customers and each other. It’s about executives being willing to answer hard questions when things don’t go as planned. It’s about having OKRs and a product roadmap that everyone can see and contribute to. It’s about dedication to diverse voices filling the seats at the table.

This is best seen in how accessible our executive team is. I’ve been able to sit down with every executive we have; they have all been more than willing to spend time with me to get to know me and help me understand their team’s objectives. They have their own daily standup out in the open where anyone can hear what’s said. They don’t sit in offices, but in a centrally located area of our office where anyone can come by and chat with them. This doesn’t mean that there aren’t closed door conversations that happen, but there is a good balance.

The second big example of our dedication to openness is our diversity goal. We want to be as diverse as the NYC workforce and are on our way to accomplishing that goal. We have this goal because we collectively appreciate that diversity is necessary for us to serve all of the various small businesses in the USA. To do that, we need be open to the voices who represent the range of the American experience.

Our CTO’s proudest contribution to transparency is our sanitized massive data warehouse. His goal: to help every employee answer questions they have about customer and member trends while also maintaining the privacy of our customers’ sensitive information. This helps product people like myself make more informed and hopefully better decisions.

Remember those Business Intelligence team office hours I mentioned earlier? I’ve become a regular and can now read and write SQL. The ability to research trends and deep dive into individual customer scenarios has been crucial in my ability to understand the current situation and prepare strategies for the future. I know other managers feel the same.

Finally, we provide extensive Learning and Development opportunities to all staff. Professional trainers brought in to teach in everything from negotiation to project management and meditation. This effort probably is not thought of as openness to others, but to me is part of that value because it shows how we want people to explore where they want their career to progress and are open to where they might grow into. I have been very impressed with the number of employees who transfer between teams as new roles are opened and how supportive their manager are of this growth.

3. Grit

I’ve only been with the company for a few months, so I haven’t had to do too much hard work or all nighters, but I love the attitude we have around the time periods when we know teams will need to burn the midnight oil.

Our business is seasonal. There are times during the year when companies renew their health insurance and choose next year’s plan options. There is the period of Open Enrollment for all of our member employees. There’s IRS reporting in the beginning of the year and what’s referred to as “Surge” when many companies evaluate changing HR providers. It doesn’t seem like there’s a month in the year when there isn’t a big something going on.

Even with all the pressure that comes from making sure tens of thousands of people get their paycheck and have access to medical coverage, we try to make work as fun and enjoyable as possible. We have team T-shirts printed with a group’s established name. Some teams work together for a few days in the Hamptons. Others have breakfast brought in every morning to make life just a little bit easier. Our leadership knows that to encourage hard work, you must reward and respect your team’s efforts.

4. Integrity

This value is the one that comes up most often as we make product decisions. It can best be summed up as doing the right thing. With this guiding principle we choose not to pass on minor rate increases for workers’ compensation insurance which would decrease many people’s paycheck by a few pennies. It’s the same reason we provide helpful tips throughout the platform to answer people’s questions and why we create countless documents in our HR Resource Center.

Integrity is part of the reasoning behind the team that I lead. We cannot fulfill our mission of leveling the playing field for small businesses if we do not serve the smallest among them. Justworks is the only PEO that insures companies with less than five employees, and it’s my team’s work that makes it possible.

But it goes beyond the product we build for our customers and their employees. The way we treat each other with respect from the executives on down is also a reflection of integrity.

The prime example of this is the “Shareholder Meeting” that Isaac and Mike Greten, our CFO, have for all new employees. Rather than having HR explain stock options, our top executives sell each team member on investing in the company. They show the most recent pitch deck for institutional investors to all of us and then provide financial advice concerning taxes generally reserved for those wealthy enough to have personal financial advisors. I have never heard of another startup that does that and challenge all of them to.

5. Simple

The final value in COGIS is simplicity. Any product manager or engineer will tell you that we are problem solvers. At Justworks, we believe the simplest solution is the best solution. We design our platform to be the easiest for admins and employees to use so that they too can solve problems using the easiest path.

Our Employee Success team optimizes internal processes for simplicity as well. When our company got too large for our twice annual retreat to feel intimate, rather than try to find one way to make everyone happy, they chose a more simple solution; give each team the budget that would have been spent and let them choose what to do. This simplistic democratization is also the way we give back to the community. Everyone gets 5 days to volunteer as they see fit.

Many companies struggle as they grow to create opportunities for employees to meet coworkers on other teams. Ours came up with a scalable solution, Random Lunch. Each month we are assigned into a group of five employees and provided a stipend to have lunch together. Is it a perfect program? No. But it’s simple and it works. So is “incentivizing” everyone to get on the bus to our annual retreat by having the breakfast sandwiches only available onboard. It’s literally the little things that make a difference.

I’ve now spent a few thousand words detailing SOME of the intentional decisions Justworks has made to become one of the best places to work, where core values ring true throughout our product and team. Possibly the most amazing thing about all of it is how simple to execute the execs make it appear.