The ultimate software development tool

Best practices on project management, issue tracking and support

What’s Your Support Tool?

Successful project management comes with certain rules, terms and tools which is not easy to achieve. For that reason, my acquaintances in the tech industry expect valuable functionality and productivity in these tools and they want to rely on their resources in order to deliver qualified work.  

While working at an IT startup, I’ve been in search of a smart solution with unique features to help me improve efficiency and I’ve started my software research based on this.

First, I found this article about Evidence-Based Scheduling on Wikipedia and thought that somebody finally started understanding what a developer needs in a project management software. Then it made me think; what more is out there?

A successful project manager is one who can track and visualize the entire project from start to finish, who could envision milestones and estimate delays. To keep pace with business and IT, project managers need support to expand their visions and make their management practices more adaptable. Here are the tips to utilize that support:

  1. Be Agile, Develop Agile: Stop thinking traditionally and acting rigid, instead focus on being more flexible and moving quicker. Either have a ton of whiteboards or find an online space but get as visual as possible in order to make quick decisions and build an accurate backlog.
  2. Do Not Manage People, Manage Tasks: As weird as it may sound, you will see the benefits once you focus on task management instead of micromanagement. Create cases to contain the necessary information to understand each task, so you can stay productive, with fewer meetings, and monitor your team’s activities clearly.
  3. Update Your Project Management Practice: Have a powerful search engine, allowing you to instantly search complete contents of cases, wiki articles, and customer correspondence. Your issue tracking tool should be your right hand.
  4. Learn From Your Past: Make accurate estimations based on your past project experiences. Make sure to log all your previous project activities, deadlines, delays, assignments and timelines to look back and compare your set goals with the actual achievements.
  5. Time Is The King: You will want to know how much work you’ve left, how much time you’ve spent on each case, ensure a balanced workload, predict project completion dates, improve estimates and deliver on time.
  6. Communicate All Deliverables and Activities: Share technical specs with your entire team, design docs and enable them in your shared library, create knowledge base articles, public documentation for customers, complete specs and user documentation.
  7. Create Step-By-Step Milestones: Divide your project into manageable tasks and assign milestones for each task you had created in order to accomplish your project goals. The milestones will help you with qualifying events and crucial deadlines.
  8. Clear Communication: Prioritize the email sequence throughout the assignments. Set automated responses where necessary and appropriate. Save time with templated, pre-created responses.
  9. TBQ (Time, Budget, Quality) Rule: Efficient time tracking, resourcefulness and smart scheduling are the key tools to fulfil the TBQ Rule. You may meet the deadline and accomplish the goals. However, your project will be marked successful only if you are able to manage your priorities effectively, use your sources efficiently and know the impact of unforeseen events.

 

Manuscript is now FogBugz

FogBugz is back … actually, we never left.  We’ve rebranded back to our origins. We began 2018 as Manuscript and we wrapped-up the year as FogBugz!

FogBugz was born in 2000, created by the legendary Joel Spolsky, following a very simple and effective philosophy: “Listen to your customers, not your competitors.” The idea was for it to be an off-the-shelf company, so FogBugz didn’t work with customized offers, rather, listen to our customers in order to build a product that works for everyone. Every time there was an interesting feature to develop, we’d put more effort into it, and build it in a way that would fit all our customers.

That’s how Fogbugz was created; a tool born from real needs and feedback from people that were using it. FogBugz became the first issue tracking tool in the market, and other competitors started to appear, trying to copy what we built.

FogBugz continued to grow, becoming everything a dev team needs to start managing a project effectively, without complicated workflows getting in the way. As customers shared more needs with us, we created Kiln, the version control tool … exactly what developers were asking for: a place to keep track of any part of their code, making it available to branch, merge, clone, push, or pull.

In November 2017, FogCreek, the company that created Fogbugz, decided to change the name of the product, and called it Manuscript, giving it a new website and changing the branding of the product.

We acquired the app in August, 2018, with big plans of giving it a new face, and improving what is already a very effective tool. Even with the new name, Manuscript kept having the spirit of Fogbugz, and was well known by that name. That’s why we decided to change the name back, to return it to it’s true essence.

FogBugz is back!

Startup Advice From Naomi Freeman

We had the pleasure to interview the coder, developer, entrepreneur and trainer Naomi Freeman last week. She shared developer tips, entrepreneurial secret sauce, her success formula and more. Here are the keynotes from our fun, honest and learning experience interview:

Startup Secret Sauce

We had to ask Naomi, who is a serial entrepreneur: what’s the secret sauce to a startup?

“You can find tons of articles talking about startup secret sauces but I think the simplest thing is to make money. That seems obvious, but when you’re in the technology space at least (and sometimes in nonprofits, too), you can kind of lose track. It’s very simple: if you’re not earning money, you don’t have a business,” she said.

If it’s such a simple secret, though, how do people get off-track?

Naomi built an AI prototype and co-founded a company around it. With that in mind, she explained:

“If you build something – and, for me, I built this prototype myself, so I was really deep in it – and the building is great but as soon as you do something cool in the technology space, suddenly you’ve got cameras on you, you’ve got venture capitalists, you’ve got accelerators coming after you. It can be really exciting but if you look on your calendar and do an exercise where you write down every single thing you do for every single hour of a week for one week or two weeks or three weeks, then go back with gold star stickers or little gold money stickers and see where you were actually doing revenue-generating activities (not trying to get venture capital).

We’re talking about meetings for partnerships, we are looking for actually talking to clients who want to pay for things and if you can’t find them anywhere on the calendar where you can put a money sticker without really stretching it, you have a problem.”

It can be exciting to be part of the Silicon Valley culture, but venture capital success doesn’t necessarily mean business success. Quite often, Naomi argues, most businesses aren’t even a good fit for the venture capital model. That doesn’t make the business a failure. It just means it’s not the right kind of business for venture capital.

Pieces Of Advice For “Entrepreneur-To-Be’s” and Project Management

What would you say to prospective entrepreneurs if you could only say one thing?

“I think the greatest advice to prospective entrepreneurs is ‘You got this! No one is gonna take you seriously, but you totally got this!’” she said.

When asked what the best advice for those wanting to dive into entrepreneurship is, Naomi stressed that there’s no single path.

“I guess, more seriously, you hear all kinds of advice about how to do a startup, how to be a founder and at the end of the day it really is a little bit unique for every single person. Some people need that support of multiple co-founders and big boards right out of the gate, some people are really most comfortable once they have a big financial partner or they’re more comfortable when they have their own autonomy.”

Given that there can be so many different ways a start-up can be structured, how do you know if you have a start-up or not?

“At the beginning with that first spark, when you move from ‘I have an idea I want to share with everyone’ to any kind of action, either you have to be all in or you have to know that it’s a great business. These are both start-ups. Whether you’re in R & D for 2 years on venture capital funding or you’re earning money but it’s not your purpose in life, you’ve still just started something. That’s a start-up.”

The best way to beat up competition with a low startup budget

“What makes a startup an unbeatable entity is the community. Again, that’s my perspective, but if it’s just me and you [two co-founders who] want to team up against the world, yeah, the wind can blow us around a lot. But if we build a community of people who come to us, who know us, root for us, it’s a lot harder to get rid of the company. It becomes a much larger, more intangible, less targetable entity.”

How do we make an unstoppable force of the community to support our business?

“There are concrete ways to build a community and it will depend on your business.

Let’s say you’re one of those subscription boxes that goes out every month – you’ve got makeup or books or food in the box. It’s really easy to put on the inside of the box ‘hey, Instagram it, tweet us, show us what you got, tell us how you’re feeling’. If it’s a book, maybe let’s talk about a book club kind of question that you post on Instagram, or blog or tweet about, where everyone can connect. In other cases, say, if you were selling socks, it could be that when you send it out – first, you make sure your boxing is amazing, the unboxing experience is like nothing you’ve ever felt before. It’s like joy comes out of that box, not just socks. Second, when you unwrap the box, there is a thank you card saying thanks so much for being part of this bigger thing.

There are different ways to create community and engage but the key is that people need a way to feel like they’re part of your team and they’re on the journey too. The funding might go but your users and people won’t.

Why are people on Facebook? Cause everyone else is on Facebook. It’s a network effect and people want to be a part of it.”

She went on to explain that you have to create that kind of community and feeling for every company. A company is not just the product(s) it’s selling. It’s also the brand identity that they sell and the community they build up around that not only shares with the company but also shares with everyone else in the community and anyone watching from outside the community.

The most common challenges developers face

What do you think the most common challenge is that developers face?

Naomi explains that the biggest challenge developers face is actually in how they connect – or disconnect – from the people around them.

“It comes back to some other things I’ve been talking about: people get inflexible and isolated. When you think you know better, even though everything around you is changing, and you cut yourself off from your team or your peers because you’re pretty sure you know better, you end up in a really dark place.

There is this myth in Silicon Valley of the individual coder – a hacker in the basement that’s doing all this crazy wire work (or whatever they’re doing) but the truth is, when grown-ups go to work, they interact with lots of other people. That’s just how modern life is.

Unless you own your own business, you don’t get the final say on ‘well, this is the future!’ Unless you own the business it’s actually not your decision what the future looks like, because what you’re really saying is that you are the best person to know what the future of the company looks like, and that’s just not true. I mean, you can take ownership for your decisions at your table but that’s within the framework of whoever owning it saying it’s okay, right?

I don’t want to discourage people but I feel like when people get a little too comfortable sitting where they are, they can end up in that place.”

We hope you enjoyed this interview and got the chance to learn a lot from Naomi’s experience, for us, FogBugz, it was very enlightening and we’re grateful to be able to share this excellent advice!

Don’t Set New Year’s Resolutions – Create Reusable Components

With the new year just around the corner, we’re entering the season of New Year’s’ Resolutions. Prepare yourself for overcrowded gyms and inspirational Instagram quotes tagged with #bigdreams.

If that’s not quite your style, I’d like to introduce you to a very different way of making progress on your goals: Component Thinking.

Instead of fixating on far-off, audacious horizons, Component Thinking has you focus your efforts on creating small, reusable components in the short term, knowing that you’ll be able to assemble them into something bigger in the future.

Digital work is made up of components

Every work product is made up of smaller parts, which I will call “components.” This is true of physical products, but it’s not very easy to take them apart and put them together in a different form. But for digital products, reuse is easy.

Any snippet of text can be copied and pasted anywhere else. Any image or video can be edited and uploaded to different places. And of course, a piece of code can be reused in different parts of a software program, or even in different programs.

Here are some simple examples of how to create reusable components:

  • If you create a lot of business proposals, make a proposal template you can use again and again
  • If you often design websites, start collecting web clippings of websites you like in a notes app
  • Instead of just updating your resume every few years, start collecting work deliverables you could show off in a portfolio
  • If you find yourself writing the same onboarding email multiple items, make it into a knowledge base article that you can reference with just a link
  • If there is a common customer service issue you have to deal with, record a 2-minute screen capture that you can upload to your website

These actions are valuable not just for one-time use, but for many possible future needs. A template for business proposals is inherently valuable, independently of any specific proposal. A notebook full of model websites could be useful in any kind of web design project. A portfolio is always a good thing to have, whether you’re applying for jobs or raising a round of funding.

Having many of these components ready and waiting gives you a few powerful benefits:

  • Each one gives you optionality, increasing the number of options you can consider
  • Each one helps you take action more quickly, because you can reuse past work instead of starting from scratch
  • Each one can remove uncertainty by testing assumptions, making future projects less risky
  • You can improve components incrementally over time, by tweaking and adjusting them each time you use them, instead of trying to make all the improvements at once

The modularity of digital work

The impermanence of digital work can often feel like a curse. Nothing ever seems to be finished. We rarely get to celebrate a clear-cut completion. But we can turn this curse into a blessing – if nothing is ever final, there’s no point in waiting to get started!

Instead of waiting until you have all the pieces in place, launch a basic version and upgrade it slowly over time:

  • Launch a beta version of your app, knowing that any component of it can be added later through software updates
  • Send out a draft of your blog post, knowing that you can update the text at any time
  • Self-publish an ebook on the Kindle platform, knowing that any update to the manuscript will automatically be synced wirelessly to anyone who has purchased the book
  • Publish a simple, one-page website with a photo and a bio, and add a new page every few months when you have extra time

Digital work is naturally modular – the various components that make up a product can be created at different times, evolve at different speeds, and be swapped in and out. We can take advantage of this modularity to make progress on our goals in small pieces, instead of in one huge leap.

Solving problems by making things

Most people solve problems through analysis, which means “separating” the problem into smaller parts. The way makers solve problems is through synthesis – by making things and testing them. There is nothing like a tangible thing placed in front of a real human being to bring a dose of reality forcefully into a project.

The best components are those that:

  • Answer questions or test assumptions
  • Simplify or speed up future projects
  • Make future decisions faster or easier
  • Need to be done anyway

People are often afraid to start on projects until they know they will succeed. But this is like waiting to cross town until all the traffic lights are green at once. It won’t ever happen. We have to make progress whenever and however we can.

By focusing our efforts on creating multipurpose, reusable components, we are preparing the ground so that we can quickly take action when an opportunity presents itself. Instead of waiting for the conditions to be just right, we are actively revealing assumptions, learning new skills, and preparing the resources we’ll need.

This new year, instead of setting a flashy resolution, try creating a reusable component.

Tiago Forte teaches people how to capture their knowledge, organize their digital life, and create reusable components, among other things, in his online course Building a Second Brain. Save $100 on the course using code FOGBUGZ (first 25 only).

Collecting Feedback From Stakeholders Can Help You Build Software That Matters

If you want to build great products that your end users will love, collecting feedback early and often is a key step in this process. You also want to ensure that you are not just collecting feedback from the end-users but also from stakeholders within your organization. No matter if it is Charly from Marketing or Cindy from Finance, everyone’s feedback plays a vital role in building the best version of your product or software.

An unwavering and fierce commitment to not just gathering the feedback but collecting, organizing, and sharing the feedback plays a vital role in pushing your product and business forward. Feedback collection in software projects is more than bug reporting. You want to collect experiences and feelings that the users have with your software. The people side of end-user feedback helps you to shape the customer experience of your digital product. Based on a Walker study, 86% of buyers are willing to pay more for a great customer experience.

Why Feedback Matters

Frequent feedback drives and informs your decision making, saves valuable time in the long run, and influences your product/software roadmap.

Feedback is also necessary for measuring satisfaction among your current customers. These are some of your most valuable stakeholders and the kinds of things you are hearing back from your current customers should definitely not be ignored. Use the feedback to create valuable action items to continue to improve your offerings.

Haymo Meran, head of product

Learning and managing how customers view your product, support, and the company overall continues to prove invaluable. By using early and frequent user testing you can uncover things customers may not know they’re thinking about or problems they may not know they’re struggling with. This will provide you with a clear path to make the product and experience better.

If you layer user feedback through every stage of software development, not just at the beginning or the end, you are able to move fast and deliver quality. You can capture feedback manually or with tools  (for internal & external feedback). With integrations available between feedback collection tools/bug tracking/user feedback applications (like Usersnap) and project management software (like FogBugz), you can cover all your bases in the need for feedback from everyone involved.

Screenshot: Usersnap + FogBugz integrated

“How To Do It” Manually

There are many manual ways to capture feedback from users in real time that can sometimes prove to still be effective. Manual feedback collection can be valuable in connecting with the people side of your software or product, especially internally within your organization. During this Digital Age, with technology keeping us connected more than ever, reaching out through email or live chat can be quick and easy. Here are some ways you can quickly capture feedback from the people side:

  • Creating a feedback survey
: Using applications like Survey Monkey, you can quickly and easily create a comprehensive survey to determine things like how the user feels about your software overall? The ease of use? etc. Stakeholders easily reach this survey through a link or from within an email.
  • Direct email and customer contact forms
: Email is one of the most valuable ways to gather candid customer feedback. Sometimes you won’t get a specific answer to your question until you ask. Many people still want to feel valued and like their opinion matters. So you can capitalize on this by simply sending an email and asking what they think.
  • Direct exploratory user interviews: 
It is very true that understanding your stakeholders and users is often as easy as talking to them directly. This can be accomplished through a face-to-face interview or through online video chat applications like Zoom.
  • Through social media
: Social media is a very powerful (and becoming more and more powerful) tool to reach your stakeholders and prospective customer base. There’s always direct comments to your probing social media post or mentions on social networks. But many social networks now have effective polling tools built in. All you have to do is simply ask a question that you want users to respond to.

The downside to manually reaching out to people to collect feedback is not on the front side, but on the backside when you receive responses. It can quickly become very difficult to differentiate the feedback and organize it so that you can learn from it and create action items. Next thing you know you’re getting isses reported, bug reports, and customer feedback from different channels all over the place. Your alerts start going crazy and you start getting pinged on Slack, email, or even in person from teammates about a button that doesn’t look like it is sized right or a request from a user for additional functionality they suggest for in the future. When feedback is reported through different channels, it quickly becomes hard for product managers to get a single backlog of all the user feedback that needs their attention—let alone organize and prioritize the most critical items for necessary immediate action.

This is why it is effective, time-saving and cost-effective to utilize powerful comprehensive tools and technology that can do this for you and allow you and your team to deliver great products faster.

“How To Do It” Effectively

Manual processes are often a lot of work. That is why we suggest a more automated way. If you utilize an automated feedback software, you can capture feedback effectively where it happens and where your users are. This software should be working inside your website or web-based application directly within the browser. After capturing this feedback you need, a software for that can manage all of the responses and move them to the appropriate development teams.

If you use a visual user feedback application in conjunction with a powerful project management software, you will quickly learn how much easier the flow of feedback into your product will become.

There is actually a powerful combination of tools available that can make your feedback collection completely streamlined. You can easily utilize the software program Usersnap for feedback capturing and FogBugz, which is seamlessly integrated, for managing thousands of feedback items.

FogBugz is a comprehensive project management software that helps you spend less time on managing and organizing and more time on creating great digital products. Through a project management system like this, you can easily align your team under a common purpose and set of goals. This allows you to plan, track, and release great software and products. FogBugz provides all you need to make great software, including project management, issue tracking, and support, fused with just enough process to help you deliver. Plus, there’s robust integration with other best of breed tools like Usersnap, Slack, GitHub, and Google Docs.

Screenshot: FogBugz

With the seamless integration of FogBugz and Usersnap, you can save valuable time and resources, and also improve accuracy in bug reporting and feedback versus manual methods.  Used by over 20,000 software development teams, FogBugz is a system that makes it easy to monitor your projects. It helps your team to focus on the tasks that need to be done. You can capture features, tasks, and customer requests in a central location.

Now that you’ve got the project management side covered you have to take a look at your testing and feedback tool side. Bug tracking, website testing, and issue tracking with Usersnap have never been easier. Utilizing the built-in point and click issue reporting, you get visual feedback and additional information faster into your FogBugz project. Now, no you don’t have to ever worry about endless bug reporting for your users again.

Once you have successfully connected Usersnap with FogBugz, you will receive annotated screenshots to your FogBugz project, along with records of advanced client-side JavaScript errors as they occur, every time a bug report or feedback is created with Usersnap. This helps to bring designers, developers, and project managers together on the same page better than many other alternatives. It is very true that a screenshot often paints a thousand words and helps you deliver great products faster.

Screenshot: Usersnap feedback widget in a website

Using a bug tracking and visual feedback application like Usersnap allows your customers or stakeholders to provide a visual description of what might be a bug in form of annotated screenshots. You also get important information such as what browser was used, the used operating system, and the exact location or URL where the bug has occurred. Your testers have the option to use a drawing pen, a highlighting tool, and sticky notes to illustrate and annotate the bug report. With a screen capturing tool enabled you’ll get so much more out of the bug reports in your project management system.

“Usersnap is a great tool for real-time user experience reporting. Our development team relies on Usersnap to effectively capture bugs and user issues as they relate to the user experience. Kudos to Usersnap for easy user adoption.” Tim Smith, HLT

You can solve your project management tickets in FogBugz faster with browser screenshots from your feedback software like Usersnap.

Get detailed information on the integration of Usersnap and FogBugz.

Screenshot: Dashboard of Usersnap

Wrapping It Up

Discovering issues and bugs during the development stage of your product or software saves your precious resources, time, and money compared to if they are just detected during testing or worse during the application launch phase. You want to utilize effective visual testing and feedback through all phases of development.

Utilizing an integration of a project management software and a user testing platform can help you keep your feedback organized and prioritized so that you can address the most pressing issues and create action items to move your team forward on.

Usersnap helps Making Feedback Matter and FogBugz helps Building Software that Matters.
Perfect combination or what? ☺

Start your free 15-days trial of Usersnap seamlessly integrated with FogBugz along with your FogBugz subscription if you haven’t already. No credit card. No strings attached.

Klaus-M. Schremser
Head of Growth, Usersnap


Evidence Based Scheduling

Evidence-Based Scheduling (EBS) is one of the most revolutionary and mindblowing features of project management software today. Joel Spolsky, the inventor of EBS, describes it best:

“Software developers don’t really like to make schedules. Usually, they try to get away without one. ‘It’ll be done when it’s done!’ they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten.

Most of the schedules you do see are half-hearted attempts. They’re stored on a file share somewhere and then completely forgotten. When these teams ship, two years late, that weird guy with the file cabinet in his office brings the old printout to the post-mortem, and everyone has a good laugh. ‘Hey look! We allowed two weeks for rewriting from scratch in Ruby!’”

Joel points out that there is a need for finding out how much of a return a project would bring, and in order to calculate this you need to first figure out how much time you need to invest in order to get that return.

“Why won’t developers make schedules? Two reasons. One: it’s a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it’s not going to be right?”

Over the years, FogBugz developed a system that’s so easy that even the grumpiest developers are using it. It’s called Evidence-Based Scheduling or EBS. You gather evidence, mostly from historical timesheet data that you feedback into your schedules.

Smart Scheduling

What you get is not just one ship date: you get a confidence distribution curve, showing the probability that you will ship on any given date.

Here’s how you do it:

  1. Break Them Down: EBS is a believer in breaking each design into steps, and maximum time allowance is 16-hours for each step.
  2. Track Elapsed Time: EBS encourages you to keep timesheets so you can keep track of how long you spend working on each task. Then you can go back and see how long things actually took relative to the estimate.  You can do this for each developer.
  3. Simulate The Future: Rather than just adding-up estimates to get a single ship date, use the Monte Carlo method to simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible scenarios for the future. Each of these possible futures has a 1% probability so you can make a chart of the probability that you will ship by any given date.

EBS is the future of project management and yet a handful of developers know about this hidden gem. Our goal is to spread the word by providing a smart tool for developers to use to help with the heavy lifting, leading to time savings and increased accuracy for their projects.

Some Feedback on EBS:

Jeff Atwood@Coding Horror: “It’s a tremendous credit to Joel Spolsky that he made this crucial feature the centerpiece of the FogBugz. I’m not aware of any other software lifecycle tools that go to such great lengths to help you produce good estimates.”

Rafe Colburn@RC3.org: “We’re rolling out FogBugz 6.0 at work, and I’m finding that I actually like the time tracking. For one thing, it’s a tool for focus. When you kick off the timer on a task, you don’t want to jump around and multitask because it will just throw off the timer. The timer feature itself is pretty easy to use.”

Scott Rosenberg@Wordyard.com: “What’s most interesting about the FogBugz is what Spolsky and his team are calling ‘Evidence Based Scheduling…’”Reg Braithwaite@Raganwald.com: “I built a prototype that did the exact thing that FogBugz is doing quite some time ago. However, prototypes are not shipping products. FogBugz is a shipping product. My prototype was not. And that makes all the difference.”

How To Onboard Software Engineers Interview with Kate Heddleston

In this interview with Kate Heddleston, an independent Product Engineer, we discuss technical onboarding. We cover why onboarding is important, the essential elements to effectively onboard engineers, the areas you should focus on, who should do it, as well as common mistakes,  made. Kate writes about technical onboarding, training and mentoring on her blog.

Introduction
Derrick:
Kate Heddleston is an independent software engineer in San Francisco. She volunteers at Raphael House and is mentoring with PyLadies and previously at the Hackbright Academy. She also speaks at conferences about a range of software engineering topics including technical onboarding, training and mentoring. Kate, thank you so much for joining us today. Do you have a bit to share about yourself?

Kate:
I’m a self-described product engineer, which means I like to build features for people, but I keep building infrastructure tools because I decide that I absolutely have to have something in order to build my websites. I talk about web application development and web application infrastructure.

Derrick:
With your experience with onboarding specifically, what led you to start talking about it?

Kate:
I noticed that there was this discrepancy in the career trajectories of men and women at startups that I was working at. I was trying to figure out why because the people coming in were of the same experience level, which is out of college, so pretty much none, but the guys over and over again would get promoted faster and get to the next level faster. That is a whole separate topic of conversation, but the big thing I noticed first was that without onboarding, women were left behind more than men. I was really confused by that. I was like, “Why is that women are hurt more by a lack of onboarding than the men?” That’s what led me to start researching and putting together my talk.

“There are 2 ways to get great engineers at your company. You can steal them or you can make them.”

The Benefits of Onboarding
Derrick:
With onboarding, if done well, what are some of the benefits?

Kate:
Basically the way I think of it is we spend a huge amount of money recruiting and sourcing engineers. We pay them huge sums of money to work for companies, and we bring them in on the first day and then we’re just like, “Whatever. I’m sure you’ll be fine in our massively complicated website that is developed and maintained by many, many people. You’ll figure it out.” We’re under-utilizing people, which is expensive for companies and people are unhappy when they aren’t fulfilling their potential. That can lead to attrition. It’s one of those things where once I saw it, I was like, “This is so incredibly obvious that companies should have onboarding.” The return on investment is incredible. It benefits everyone. I came to it from a place of, “Why are women being left behind?”, but at the end of the day, onboarding is really for all humans. It’s one of those things where you get so much more out of employees who are happy and productive and feel integrated into the team, so why wouldn’t you do it?

Getting Started with Onboarding
Derrick:
Who within an organization should be involved in onboarding?

Kate:
Pretty much everyone. ‘It takes a village to raise a child’ kind of thing. The common first approach to onboarding is to place new employees with really senior mentors, but mentoring is actually really hard. It’s a lot like teaching in the sense that it’s very emotionally draining. What happens is … This is experience when companies hire a lot of junior engineers. What happens is they burn out all their senior mentors. They get tired because teaching is hard, and they’re like, “We can’t take on any more junior engineers. We can’t take on a lot of new engineers who aren’t really senior.” If you spread out the load, so if instead of pairing every junior who comes in with a super senior engineer, you pair them with the last people who joined, like sophomore engineers, how they do sports in high school and college, you can start to spread out the load because the best person to teach something is usually the last person who did it.

The best person to help someone set up their development environment is the last person who joined, regardless of seniority. The best person to teach someone about a particular part of the product is the last person who developed on it. That way you can spread out who is helping who so you don’t burn out people emotionally. In fact, really senior people are not necessarily that great at teaching junior people. They’ve forgotten what it was like to learn things for the first time so it can be really painful. It’s nice to have the intermediate people turning around and teaching because they grow a lot.

Derrick:
Do you just start onboarding a new employee from their first day on the job?

Kate:
The way we’ve recommended setting up onboarding plans is setting up goals and then making them happen. For a lot of companies, if they have good enough infrastructure, being able to ship something on the first day is a really good goal. This new engineer comes onboard and in their first day, they actually push something to production. Even if it’s just a small bug fix or I don’t know, some config files that you might need for something, it’s a really nice thing to feel like you can contribute on your first day, especially as a software engineer. Setting up goals like that and setting up goals for when people are able to manage their own projects or work independently, the thing I say, the goal with onboarding is what I call reliable independence. Someone is able to reliably and independently build software on your team. For someone who is really senior, that might take 2 weeks, which is awesome. For someone really junior, that might take more like 6 months.

Derrick:
What steps or first things do people need to do when implementing employee onboarding?

Kate:
There’s no real good literature out there on exactly how to set up an onboarding plan. It varies hugely depending on the size of the company and the quality of their internal tools. I’ve talked to companies where we’ve sat down and the first thing I’ve said is, “You actually need to dedicate probably 2 or 3 engineers to building internal tooling because if everyone has to come in and manually set up everything, what you have is this super painful onboarding process that’s just going to bottleneck your company.” One of the first things, I think as an engineer, that you should do is automate things. Automation is great. People should be able to get set up really easily with their development environment. They shouldn’t spend a lot of time having to do all these installations that you do once that have no learning value. That’s the first thing I think companies should do.

The second thing is put together a Trello board and come up with some goals of what you want to see. You can section it basically by the rough seniority level of someone coming in: senior, mid-level, junior. Just knowing that someone who is junior is going to need a little bit more hands-on attention and someone who is senior is probably going to want freedom earlier. Then just set up goals of what you want to see them doing in the first day, the first week, the first month. I know a lot of people at companies who care a lot about this are often newer employees who went through bad onboarding and junior employees who went through bad onboarding. I think one of the big things for companies that I recommend is executive level signoff because there’s nothing worse at a company than fighting a Director of Engineering who is like, “Do we really need onboarding?” You’re like, “Yes, yes, we do.”

Derrick:
Beyond those first things, what else can you try?

Kate:
There are 3 major categories that people need to develop in in order to become reliably independent. They’re each about a third of what someone needs to know. We focus a lot on technical knowledge. Everyone is like, “Getting someone onboard is about teaching them about Python or whatever technologies we use.” I say that’s only about a third of what they need to know to be an engineer at your company. Another third is company structure, the internal tools that you have, the way that you build, the way that your code is set up. That’s another third of the knowledge that somebody needs. It’s basically domain specific engineering knowledge which is huge at companies.

Another third is personal development, things like confidence, the ability to research problems, the ability to debug independently, a judgment which is huge. Probably the single most important thing in most engineers is judgment. That’s another third of what people need to develop. I think focusing on each of those areas is really good. People are going to come in stronger in different categories. Everyone is going to come in not knowing that much about your internal company structure, but some people might have more confidence, more debugging skills. Some people might know a lot more about the technologies that you use. Just filling in the gaps in the areas that they aren’t as strong in.

“If you can’t hire any junior engineers… into your organization, you have serious problems”

Creating the Best Environment for Onboarding Junior Developers
Derrick:
Is there anything else somebody could do to create a great experience for junior engineers in onboarding?

Kate:
Recognizing a few things about the beginners is very important. First pairing them with someone who is one level above is actually most effective. Second, one of the tenets of expertise is the ability to recognize boundaries and scope really well. One of the tenets of being a beginner is that you cannot recognize boundaries and you are unable to scope problems and scope your world. Expecting a junior engineer to be really good at scoping a feature is unrealistic. That’s one of the skills that they have to learn. Whatever you give them to do, just scope it. Then let them go play. Give them a feature that’s really well defined, that has a clear area where they’re working on and then let them go and fumble around with it. I always tell beginners, “If you come across an issue, research it for an hour and then come talk to me.” It’s not to be mean. I’m happy to answer questions. It’s just that learning to research something on your own is really valuable and figuring out things on your own is also really valuable.

The final thing for junior engineers and beginners, in general, is helping to bolster confidence. Some people do come in and they have an overabundance of confidence, but there’s a lot of people who come in who are very insecure. People think that confidence follows skills, but it’s usually the other way around where skills follow confidence. If someone feels good about what they’re doing, they’re more likely to explore it and ask questions and to believe that they’re able to solve the problem.

Derrick:
You’re a proponent of weekly 1-on-1s, including 1-on-1s with anyone in the company, why do you think that they’re so important?

Kate:
I think talking to other people is really valuable. There’s a whole industry where you can pay to go talk to someone for an hour every week about your problems. I think people need to be heard. I also think that a huge part of what managers should be doing is listening. It forces managers to listen, hopefully, and it gives people an outlet to talk about things. I also think that you should have channels of communication that are open at all times. One of the arguments I hear against 1-on-1s is that very often engineers will come in and they’re like, “Everything is great. I’m fine. I’m super happy.”

I’m like, “That’s awesome. That is so great that your employees are really happy, but if something bad happens, they’re not going to want to have to schedule an emergency meeting with you. You should have open channels of communication so that they can come to you at any time and be like, ‘You know what? Something happened. Things are not good this week. I am unhappy about something.’” Having a constant rapport makes it easier for them to come to you in bad times, which is really what you want. The communication channels and 1-on-1s and things like that are just to set up relationships so that people feel comfortable coming to you with bad news, which is actually a very difficult thing to do.

“I always tell beginners, ‘If you come across an issue, research it for an hour and then come talk to me.’”

Common Onboarding Mistakes
Derrick:
When organizations are onboarding, what are some common mistakes you’ve seen?

Kate:
The big ones are burning out senior mentors. Then that leads to, “We can’t take on any more junior engineers,” which is a huge travesty. When I hear companies saying that “We only hire senior engineers,” I’m like, “Who do you think is training all of these senior engineers? Where do you think they come from?” There are 2 ways to get great engineers at your company. You can steal them or you can make them. In this day and age, you’d probably better have outlets for both. You should have a sustainable program of bringing on junior engineers. Depending on the size of your team, sure, you might only be able to handle a few at a time. Totally fair, but if you can’t hire any junior engineers if you cannot hire any beginners into your organization, you have serious problems with your team structure and your internal tools probably and basically everything that has to do with bringing someone new onboard.

Let’s see, other common mistakes … Bad internal tooling. This is the whole infrastructure thing that I get on. Having a really good infrastructure means not only can you deploy code quickly and reliably, which is what a lot of people talk about, but it means that you can also bring new people onboard. If you have a really easy to use a robust system for testing all of your code and deploying it, that is much, much easier for someone new to learn. It’s also a great system for people who are beginners. It’s robust. It’s easy to use. We can train a junior engineer to deploy code. Some of the best things I’ve seen for web applications are 1-click deploys, being able to deploy code to any service with the click of a button is great. Similarly 1-click rollbacks, really good, integration testing and things like that.

Derrick:
Kate, thank you so much for joining us today.

Kate:
Thank you so much for having me.

We’re Bad At Interviewing Developers (and How to Fix It) Interview With Kerri Miller

In this interview with Kerri Miller, Lead Software Engineer at LivingSocial, we discuss how to hire and interview developers. We typically don’t get trained on interviewing and we’ve all experienced the haphazard approaches of those new to it – poor organization, repeated questions, fizz-buzz… Kerri tells us how to run interview days, the types of questions to ask, how else we can evaluate candidates and what to do after the interview. For more tips, Kerri writes about software development and hiring on her blog.

Introduction

Derrick:
Kerri Miller is a lead software engineer at LivingSocial. She is also a RailsBridge instructor and frequent conference speaker. She talks about software development and hiring, including the talk, ‘We’re Bad at Interviewing and How to Fix It’. Kerri, thank you so much for taking the time to join us today. Do you have a bit more to share about yourself?

Kerri:
I am actually, in fact, a lead software engineer at LivingSocial. Part of that is working with junior developers, or more junior developers, leading software teams and projects, and I also do a fair bit of work in our engineering culture team, so doing things like how do we propagate a good culture for code reviews, post-mortems, and hiring.

“You want them leaving the interview process regretful that they didn’t get hired, not resentful that they didn’t get hired”

What’s Broken with Developer Hiring?
Derrick:
What do you think is broken with the current way a lot of companies hire and interview?

Kerri:
We don’t do a really good job of hiring with intent. We decide that we need more people, but we don’t do a really good job of figuring out what we need those people to actually do, and who we actually need to hire. I like to think of my software teams as little ecosystems, little, tiny arcologies that exist in a bottle. They’re not entirely a closed environment, and, like any ecosystem, anytime you introduce anything new to that realm, there will be changes. There will be impacts.

Any time you hire somebody, you’re changing that ecosystem. You’re introducing a new species or a new variable to things and it’s going to change. Thinking about what you want to change means that you have to have laid that groundwork to understand where you are at the moment. A lot of teams and companies don’t do a really great job of understanding that. They’re just simply, “We need more bodies. Let’s hire bodies.” They don’t go into these things with a conscious sense of where they are and what they need, and how the future’s going to change by adding more people.

How to Structure and Run Interview Day
Derrick:
Let’s talk about the interview day. How should we structure it, and what are some key aspects you need to get right?

Kerri:
You need to go into it having a plan, and that plan starts with knowing what questions you’re going to ask and why. Understanding that every question you ask that a candidate can’t answer, or every step of that process is an opportunity for a candidate to filter themselves out of that process, it’s a point for you to get information to make that final decision. I think it’s really important that you take a look at what that plan is going to be. If you have, say, three people, and you’re hiring for a front-end developer, you should have one person ask about JavaScript. You should have one person ask about, perhaps, browser interaction, or working with designers, or what have you. Just splitting up that interview so that you’re not asking the same questions over and over again, you’re really able to get really solid signal on a person’s skill sets, what they’re comfortable with, and what their concerns are. What kinds of decisions are they making?

Good Types of Questions
Derrick:
What are good kinds of questions that we should be asking?

Kerri:
Well, I’m not a big fan of whiteboarding, because I think that’s something that we just automatically do, and we don’t think about, “Well, what questions are we trying to answer by asking a candidate to solve a problem?” Are we dinging people for trivia questions, for not remembering, “Oh, I need this third option flag or an obscure method from a core library.” Instead, I really want to focus on questions that are asking about decisions that they’ve made, what choices have they made, and what choices would they make again in the future? Are they reflective about mistakes that they’ve made? Are candidates looking for opportunities to improve, and how do they actually go about it? Do they make plans for themselves, like how they would improve a certain skill set, whether that be a technical skill set or a more soft skill set, for example, management, or project shepherding for example. Those are the kinds of questions that I think really get you at the heart of not necessarily what somebody knows, but what they’re capable of.

Beyond the Interview – How Else to Evaluate Developers
Derrick:
You’re a proponent of evaluating candidates in other ways than just an interview. How else should we be finding out more about potential employees?

Kerri:
I’m a really big fan of pairing on projects, like actually working with somebody. It doesn’t have to be a formal or traditional pair programming situation with one computer and two people, talking through the technical choices that they would be making as they programmed on something. At LivingSocial, we do a code challenge like a lot of companies do, using that as, then, a launching pad to have a discussion with a candidate to say, “You solved the problem using this technique. Why didn’t you choose this other technique? Why did you choose this one? How would you do it better? What if we sat down and refactored?” That’s one really good way to really get the heart of why are they making the decisions they’ve made? Not just did they make this choice because they didn’t know, or are ignorant, or did they make this choice because they had a certain belief about what the requirements of a given project were? That’s one way to do it.

Other ways you can be finding out more about potential employees … I’m a really big fan of asking the employee to explain something to me or teach something to me. In the past, we’ve done this with simply just saying, “You can teach me anything, something that I don’t know, and preferably is non-technical.” How well do they communicate about something that they’re a local expert in but they’re intended audience is not? Could they then go off and go and learn a new framework, or go have a meeting with, perhaps, a stakeholder, or a client, and come back and explain what the actual requirements are to me, to distil down what I need to know and communicate that well? Communication is such a big part of what we do in this job, and so testing for that essential skill in a really clear and explicit way can be really useful and get you a really good signal about who that candidate is and how they’re going to fit into your organization.

“We don’t do a really good job of hiring with intent”

After the Interview – Making the Hiring Decision
Derrick:
After the interview, what are key things that employers should be doing?

Kerri:
I think it’s really important that we don’t just say, “We’re going to get back to you,” but to say, “We will get back to you by Thursday, end of the day.” Then, if you can’t make your decision within those three or four days, communicating that to the candidate so they have expectations that you can meet, because it’s not just good for the candidate, it’s good for you as a company to have that discipline, because you want people to, whether you hire someone or not, you want them leaving the interview process regretful that they didn’t get hired, not resentful that they didn’t get hired. Being professional and upfront and just friendly and encouraging about the entire process is great.

I try always to make sure that, if we can’t hire somebody for whatever reason, we make sure that we give them constructive advice or feedback afterwards, or at least make that available. If you did like somebody, if it came down to either Joe or Mary, and you hire one or the other, keep that person on file, and follow up with them in a few months to see how are they doing, what’s going on? “Hey, we have an open position, would you like to re-apply, or would you like us to consider you for that?” That gets into the part of how you keep metrics on things as well because if you didn’t hire somebody, figure out why you didn’t hire them and then follow up and see, are they actually doing that work, and did we hire the … Not necessarily the wrong person, but did our process let us down? If you assume that somebody didn’t know anything about, say, SQL, and now they’ve gone on to work on a SQL-heavy project, for example, what in our process missed that step?

“It’s really hard to look at who you hire and decide that you have a good or bad process. But you can look at who you don’t hire.”

Derrick:
Great, so we talked about having a plan as part of the hiring process, what’s a good process to follow to make a hiring decision?

Kerri:
When you split up the interview topics, the questions you’re going to ask, and you’re going to consistently ask all of your candidates, it feels a little bit like reading a script, but it really lets you compare apples to apples as much as possible. Once you’re done with your little section of the interview, you should immediately go back to your desk and not get back to work but write down what your impressions were. What were the pros and cons, the bullet points, and find something good about the candidate and something not-so-good about the candidate, something that you wish they did have? Doing that at that moment and passing that back to a central person so as not to … Don’t pass it back to a group, pass it back to a central person, whether that be an HR or the hiring manager, to collect that, so you’re not coloring the impressions of other people.

When you get back into that room with everybody else, whether it’s virtual or real, to really discuss your opinions, you’ve got your opinions of the moment and you can’t be swayed by the impressions of somebody else. For example, if you were supposed to interview them about JavaScript, and the senior JavaScript person, who’s got twenty years of experience in JavaScript, just really did not like that person, how would that color your opinion if you had to give your opinion in that moment? If you wrote it down previously, no, this person really is good at JavaScript, then you’ve captured that honestly and you can really give honest feedback about what that person’s qualities are and what their strengths are without being colored by other people in that discussion.

Measuring and Improving Your Hiring
Derrick:
You hinted at this earlier, but a key part of your approach to hiring is measuring the process to improve it. How could we go about measuring the effectiveness of our hiring?

Kerri:
It’s very seldom that we ever hire anybody bad. When you hear horror stories about hiring, it’s always somebody else’s team that hired that one jerk, or that one idiot, so it’s really hard to quantify because now we know that person, and we’ve worked with them, and we understand their strengths and their weaknesses. It’s really hard to look at who you hire and decide that you have a good or bad process. You can look at who you don’t hire. You can look at that in terms of what were the false negatives? Did we bounce this person out of the process for a specific reason and then it turns out that that reason wasn’t good based on where they ended up going to work?

It’s really easy to LinkedIn stalk people, and peak into their GitHub profiles if they’re doing that sort of work, to see what they’re doing a few months later. It can be really useful to, four, or five, six months down the road, go back and look at the candidates that you passed over and see what they’re doing to understand, if you keep records of the questions that you ask, and the reasons why you maybe didn’t hire somebody, to see if those reasons are still valid.

Other metrics that I think are really, really important to an organization are understanding what your pipeline for candidates consists of. At each step, you have a certain amount of leakage, because people just simply don’t make it through the process or they abandon the process, they disappear. How many people are you losing at each step, and is there one step that you’re losing a lot of people at? Maybe you need to refine that step, remove it, or move it earlier or later in the process based on what your organizational needs are. I think it’s also important to look at who you’re losing as well. Are you losing junior developers at a step that you really don’t want to be losing them at? Are you losing more diverse candidates? Are more women abandoning your process at a certain step than men are, and understanding, or questioning at least, your process to see, is that a problem? Can we fix it? How do we fix it?

“You should immediately go back to your desk, and not get back to work, but write down what your impressions were”

Common Developer Hiring Mistakes
Derrick:
What are some common mistakes you see companies making when hiring developers?

Kerri:
Some of the more common mistakes are hiring from our friend networks. I think that the friend network is such an important part of how we get jobs, but it also tends to reinforce our monocultures a little bit. We tend to be friends with people who are mostly like us, and so those are the people that we’re going to be recommending, and so those are the ones that get hired more often. When I was mentioning earlier how the team is an ecosystem, it’s important to have some diversity there, and not just the diversity we talk about in terms of gender or ethnicity or race, but age, class, looking at people’s technical backgrounds, do they come out of CS programs versus being a self-taught or a boot camp?

Industry backgrounds, did they work in, perhaps, consumer electronics testing before they became an SDET at Microsoft? Were they at startups versus large enterprise companies, or somewhere in between? All those pieces of diversity are going to be influential and improve the health of the ecosystem of your team, and so those friend networks are important for getting candidates in the door, but understanding that that sometimes is going to lead to a certain amount of self-selection for candidates.

You have to, like in soccer, they say, “Run to where the ball will be, rather than where the ball is.” If you have those early conversations about who you need to hire, and what you want to look for, what sort of energy and person do you want to add to your team, to influence it into a good direction? And then go to those people, find them, whether it be through meetups or user groups, or extending your extended network, not just your immediate friend network.

Derrick:
Are there any other resources you can recommend for those looking to improve how they hire developers?

Kerri:
Looking at the different boot camps you’re doing, and how they’re talking to their students, as well as to their sponsoring companies, or the companies that are hiring. I’m a really big proponent of hiring more junior developers, because no one is ever going to know our exact technology stack and our exact way of working, we always have to teach people, so looking at what those boot camps are doing, and how they’re talking about the industry, because they’re trying to set people up for success over the next five years. There’s a lot of wisdom. They’re spending a lot of time to gather wisdom that they can relate to us about who we should be hiring over the next five years, and what skills we should think are important.

Finally, I tell everybody this, go take a relationship skills class. Although they’re sold as being aimed at couples, a lot of that is really about listening to other people and understanding what their concerns are. Once you can start to build those sorts of skills for understanding the perspectives of other people, just generally improves everything about your hiring process, and your team, and how you work with each other.

Derrick:
Kerri, thank you so much for joining us today.

Kerri:
I’m really excited about this topic. I’m glad to see more and more people talking about it. There’s no one size fits all solution. We all face some really unique problems, but there are some commonalities.

Improve Your Culture With These Team Lunch Tips from 20 Startups

The importance of eating together has long been recognized in positive child development and strengthening family bonds. Eating together is a great equalizer and it can be a good way to help form better and more valuable relationships amongst teams of co-workers too.

I would encourage the companies to have rows of long tables. Having round tables means that when looking for a place to sit, you have to pick a group of people. But with long ones you just go and sit at the end of the row. You end up speaking to different people every day, helping to avoid cliques. It’s good for new hires too – they don’t have to sit alone or force themselves upon an unfamiliar group.

Like StumbleUpon, AirBnB, Eventbrite and others, you may have the lunch catered. It would be served up at the same time every day so everyone knows when there will be people around to go eat with. For the foodies amongst you, the employees would be sharing photos of some of the tasty dishes on company Facebook page.

Others, like MemSQL and Softwire have hired in their own chefs. And of course, there are the likes of Facebook, with their own on-site Pizza place, Burger bar and Patisserie, and Fab, who have their Meatball Shop and Dinosaur Bar-B-Que.

It Doesn’t Need to be Expensive

It doesn’t need to be expensive though – you don’t have to provide the food, people can bring their own lunch. The important part is the set time and place to eat together. Make them optional, so that people don’t feel obligated and can get on with critical work if need be.

If space is a problem, then eat out. A group at Chartio for example, eat together at a different place in San Francisco every day.

Can’t do it every day? No problem. Take Huddle, they have a team lunch once a week. FreeAgent do tooand they keep things interesting by picking a different cuisine from around the world each time.

Stay Productive

TaskRabbit, Softwire and Bit.ly have their ‘Lunch and Learn’ sessions. One team member presents on a particular topic of interest, whilst the rest munch away. Twilio use their team lunches for onboarding new hires, who demo a creation using their API to colleagues in their first week.

Small Groups or the Whole Team

It doesn’t have to be the whole team either. Warby Parker, for example, has a weekly “lunch roulette,” where two groups of team members go out and share a meal. HubSpot allows any employee “to take someone out for a meal that they feel they can learn from”.

Get Creative!

There are many creative ideas, too. Shoptiques provides lunch with its Book Club, LinkedIn gets in food trucks every Friday, and GoodbyeCrutches have themed lunches – “Jimmy
Buffet Day, Smurf Day, and Pirate Day” being amongst their favorites.

No Excuses

You don’t even need to be in the same country! Crossover holds virtual team lunches where its employees from the US, Russia, Brazil, Romania, Turkey, Uruguay and India gather together and eat whilst in a Zoom meeting room.

So there you go, there’s no excuse to have another sad lunch, sat alone at your desk reading some random blog post…

How have you improved team culture at your workplace? Tweet your tips to @fogbugzteam and we’ll re-tweet the best ones.

 

7 Ways to Get More Out of Beta Testing

The weird and wonderful bugs that get thrown up when real users first start using your code never ceases to amaze. There’s always some odd edge case that had been overlooked, despite you think about little else for several weeks. We’ve been through this many times and concluded that beta testing is the solution to our problems.

Here are 7 things you can do to get the most out of our your beta tests:

  1. Ask for a commitment to provide feedback:

Response rates will be higher if you ask your beta testers upfront to commit for providing feedback. This doesn’t have to be formal, it could be just a part of an application form. But having agreed to it, people are more likely to follow through.

  1. Do not release with known bugs:

Most beta testers will only provide feedback once so you don’t want to burn any tester to just hear about known issues.

  1. Allow enough time:

Use the following as a rough guide. For a major development effort, say about a year’s work, you’d want to spare 10-12 weeks for beta testing. Decrease as necessary – so if it took a month to develop, then, around a week will suffice.

  1. Be feature complete:

Only beta test when your feature complete. Adding in things as you go sets you back to the start. Otherwise, it just means the new code and its impact on existing functionality isn’t as well tested as the rest. Something you’ll regret later.

  1. Make it easy to get in touch:

You want to make it as easy as possible for your beta testers to provide feedback. Give them direct emails and offer to jump on a Hangout/Skype if they’d prefer.

  1. Follow up but don’t annoy:

While your product might be front and center for you, it’s not going to be that way for your beta testers. You’ll want to remind them along the way. However, don’t overdo it, they’re helping you out so you don’t want to annoy them with too many emails.

  1. Don’t forget to provide feedback:

Make sure to send them updates during and after the tests about how you are putting their feedback to use. People like to know that their time wasn’t wasted. And don’t be tight with the swag – a free t-shirt can do wonders!

 

« Older posts