The ultimate software development tool

Best practices on project management, issue tracking and support

Tag: project management (page 1 of 2)

Direction-Autonomy Model

Management is not about being in charge.

We usually associate the term “manager” with people managers. At first glance, a people manager’s job consists of bossing people around – telling them what to do. For example, engineering managers no longer write much code, but rather focus on organizing teams.

But a typical engineering team has a second manager – a product manager. The PM typically lacks formal authority. They are responsible for defining some work that should be done, but can’t actually tell anyone what to do or how to do it.

And yet, the PM is still a manager.

The responsibility of management is not simply making decisions and then passing them on to someone else for execution. The responsibility of management is to create an environment in which decisions can be made and work can happen. A manager does not need hiring and firing authority in order to do that. In fact, John Cutler’s litmus test for what makes a good manager is precisely the reverse – to ask “if your team could choose whether or not to hire you, would they?”

Dimensions of Decision-Making

And yet, the PM needs to make decisions. What’s more, those decisions need to stick. Nothing undermines team confidence like flip-flopping between ideas and making it impossible to plan ahead. This is the real value that a manager provides to the team – the ability to set the course and keep it steady, guiding efforts towards some useful outcome.

But it would be a mistake to model this on one axis, with decisiveness on one side and indecisiveness on the other. There are two components that contribute to the “stickiness” of a decision – direction, and autonomy.

direction autonomy quadrant

Direction

Imagine your typical product manager. Let’s call them Pip. Pip’s day-to-day involves communicating with the business to keep tabs on the strategy and metrics handed down from more senior management. Pip also takes requests coming in from other stakeholders. Before asking the team to start working, Pip will usually take some time to understand the problems more deeply and figure out what a solution might look like. The fidelity of that solution – informed by Pip’s understanding of the problem and ability to define how to address it – represents the magnitude of the direction that Pip is providing to the team.

Thus, direction flows from the organization, through Pip, into the team. If Pip is providing a low magnitude of direction, they might be creating open-ended backlog tickets, or asking to improve product-level metrics that could be raised through many different kinds of intervention. If Pip is providing a high magnitude of direction, they would write highly detailed specifications and measure success through very specific, feature- or screen-level metrics.

Autonomy

If direction is the fidelity of Pip’s requests to the team, autonomy represents the extent to which the team feels empowered to define their own work. A highly autonomous team can challenge Pip’s requirements and understanding of the problem. A team with low autonomy is compelled to deliver only solutions that the PM has already defined.

Autonomy is a function of the balance between Pip’s team-facing influence and org-facing influence. If Pip’s ability to influence the organization is low, all they can do is take orders from more influential colleagues, and try to fulfill them. If Pip is influential in the organization and can manage stakeholders effectively, they can give the team a high level of autonomy. If Pip trusts in the technical and problem-solving expertise of their team, they can provide air cover against the rest of the org, while the team investigates the problem and potential solutions.

The Four Quadrants

The combination of these two dimensions gives us four possible operating modes.

A skilled PM knows how to shift between them to achieve the current most important goal efficiently. However, each operating mode has a failure mode associated with it, where autonomy and direction are not sufficiently balanced, and the team’s decision-making ability breaks down.

Dithering

A team is operating in the first quadrant if they have no external direction, and no autonomy. All they can do is dither aimlessly. Without either a solid direction to follow or the autonomy to find some way forward themselves, the team has no way to make progress on goals because they don’t have any stable goals in the first place. This usually happens when business leadership has failed to adequately set product goals.

direction autonomy quadrant dithering

Like the rest of the team, the PM is not contributing a lot to the organization. Pip spends most of their time copying stakeholder requests from emails to tickets. Priority can change at any time, so Pip can’t commit to studying the problem in more detail. Without a good understanding of long-term goals, and lacking any success metrics, Pip’s only real option is to double down on output. Melissa Perri outlines in detail how to escape this “build trap.”

Pip might be stuck in this quadrant if they or their management are afraid of risk. Risk-reducing strategies are key to moving away from this mode of work; teams should focus on increasing the frequency with which they ship, reducing the scope of each release, and gathering metrics from each iteration. If a release fails to deliver on the desired metrics, it’s not a failure, but a sign to try something else. Releases should be treated as experiments, and an experiment can never fail – it merely produces a negative result, which still contributes to the team’s understanding of the problem space.

Delivery

If the org is willing to take some risks, Pip can start placing bets on which solutions might make an impact on important problems. If Pip has not secured much autonomy for the team, but is able to give a high magnitude of direction, it’s easy to make a decision and then stick to it. There is only once decider. The team focused on delivering to the provided specifications without being encouraged to push back or question the effectiveness of the prescribed solution.

direction autonomy quadrant discovery

This mode of delivery can work if the team is tackling a well-understood problem. If Pip has the necessary domain knowledge, or has help from outside the team, the engineering team will have everything they need in order to execute the plan. This is the working mode most commonly associated with waterfall delivery models, as well as Scrum. If the business relies on consultants and agencies, or is structured around domain-specific silos, this may be the only choice they have.

The results of working this way hinge entirely on how well the problem was actually understood. Often, the answer is “not as well as you thought”. If the team has sufficient autonomy to pivot away from the prescribed solution, they can still deliver some value, regroup, and save the day. It pays to give the experts room to reach the right outcomes, rather than over-prescribe outputs.

But if the PM has not given the team any autonomy at all, and turned them into nothing more than pixel-pushers, then there is no way to alter course. This mode of delivery becomes nothing more than ruinous micro-management. By trusting the specs more than the team, the PM dooms the entire project to failure.

Discovery

PMs often try to avoid the above outcome by making a really, really good plan. A perfect plan that will anticipate every problem. But “perfect” is the worst enemy of “good enough” – and so the chase for the perfect plan usually proves futile. Not in the least, this is because a perfect plan has to involve a very low-level definition of what needs to be built, and few product managers are interested in, or capable of, getting that technical. PMs trying to anticipate risks are better off working with the engineering team and leveraging their technical expertise.

direction autonomy quadrant direction divergence

If Pip trusts the team to design a good solution, they only need to provide a small amount of direction. As long as the team understands the objectives of the project, they will be sufficiently empowered to explore many possible options, and iterate towards an outcome that moves the needle in the right direction. This is the mode you would expect to see in Lean teams, or cross-functional teams that have their own embedded designers, user researchers, and so on.

Because this mode of working has very high uncertainty associated with it, Pip needs to give the team a tremendous amount of air cover. If Pip can’t convince stakeholders that research is necessary in order to ultimately deliver better quality outputs, it can spell trouble for the team’s reputation. And without a certain amount of guidance from Pip, the team’s efforts will spin out of alignment and cease to make progress towards the end goal. Frequent iteration and a laser focus on learning are must-haves if you want to operate in the Discovery mode and not wipe out.

Synthesis

Most of the time, Pip will probably have neither the sway to run in an unconstrained Discovery mode for long, nor the time to put together a spec detailed enough to focus exclusively on Delivery. A balance between autonomy and direction will result in a synthesis of the two other modes.

direction autonomy quadrant synthesis

A team in this mode is empowered, but not autonomous. They have the strategic direction they need from Pip, and the freedom to make tactical decisions. The team has an understanding of the most important metrics that the project needs to push, and Pip has engaged the appropriate experts in order to figure out the general shape of a solution that might push those metrics most effectively. This is fairly typical of an organization where Agile is practiced correctly.

But when a strict top-down direction comes up against an empowered team driving a bottom-up initiative, the result can be simply unproductive conflict. PMs facing a deadlock between strategic and tactical needs must tread carefully, or else leave feelings hurt on all sides.

Moving between zones

As a project progresses, conditions around the team’s work will likely change. If the team has been shipping frequently and gathering user feedback, the need for discovery will progressively decrease. Deadlines will loom closer, and transitioning into a delivery-focused mode will help meet them.

But early on in a project, it will usually be more beneficial to do the opposite: secure as much autonomy as possible for the team to get a feel for the problem, explore fruitful directions for solving it, and maybe even push back against the initial definition. Cutting the period of discovery prematurely may significantly limit the impact that the ultimate output will make.

direction autonomy quadrant discovery

 

Pavel Samsonov is a Product Designer at Bloomberg Enterprise. Interested in collaboration between human and machine actors, Pavel is currently designing expert user experiences for Data License products across the GUI, API, and Linked Data platform.

You can connect with Pavel via Twitter:

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.

 

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.”

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.

A Guide To Open Sourcing Your Project at Work

Congratulations! You’ve written something at work that is amazing and you want to share it with the world! This guide covers three key areas that you should consider before making the leap: Why, when and how to do it.

Why Should I Open-Source My Work Project?

Open-sourcing your project at work can be a great idea. It can:

Help you build a developer-friendly brand

  • From those with a developer-focused product, like Stripe and Twilio, to those with APIs, like Facebook, Google and Square. Open-sourcing your code can be a good way to build your company’s relationship with developers.

Allow you to give back to the community

  • Just think of all the libraries and software you use on a daily basis that make use of open-source code. Adding your own is a good way of paying it forward so that others can benefit from your contribution. We’ve open sourced a number of libraries and even whole products.

Help you to recruit

  • Take Yahoo and LinkedIn for example. They’ve found that through their commitment to Open-Source projects (like Hadoop and Kafka), that they’ve been able to encourage developers to join them who otherwise might not have.

Gain more contributors than your project ever would have in-house

  • Like for example Square’s Dagger, a dependency injector for Android and Java. Having released it, many developers are contributing to it, including those at Google. In fact, Google developers have been contributing more than Square’s developers do themselves.

When Should I Open-Source My Work Project?

There are two conditions that you would want to meet before open-sourcing your project. You want to make sure that:

It won’t hurt your business

  • It may be an impressive, complicated bit of code that would be useful for other products beyond your own. Yet if that development is your secret sauce, then giving it away would be bad for the business. Likewise, if your library is an integral part of what makes your product unique or even what makes it possible, then you might want to keep it in-house.

Your code is helpful to others

  • Consider whether anyone else would actually want what you’ve created. Is it so uniquely tied to your workflow or infrastructure that it wouldn’t be useful for others? As a rule of thumb: if making it suitable for general consumption would make it less useful for yourself, then it’s probably not worth the effort.

Ok, so you’ve met those two requirements. Then let’s move to the mechanics of open-sourcing some code.

How Do I Open-Source My Work Project?

Step 1: Audit your code for security leaks

  • Chances are higher than you might like to admit that you or a colleague have left some passwords, usernames, IP addresses, machine names, personal contact information or other security hazards somewhere in your code. Keep in mind that this applies not only to your final master code but also to all the changesets you’ve had in the past.

For that reason, we recommend you do two things:

1. Make a brand-new repository
  • Chop off all the history of the code up to that point. There will be a new history and it saves you having to audit all the historical versions of your code. Plus, no one needs to know that it took you two weeks to wrap your head around C++11 lambda syntax.
2. Audit the code for security problems
  • This will take a lot less time than you think. Look especially at test suites and any places that are near connection points to other systems.

Step 2: Strip your code of profanity and immature pot-shots

  • While you’re in there, also rip out anything inappropriate that makes you sound more like a teenager than a professional. This doesn’t mean you can’t have any humor in your source code. But it does mean that jokes made at the expense of your competitor, a customer or the decrepit browser you’re forced to support might not be appropriate.
  • If in doubt, think about whether you’d feel comfortable reading your code loud to those beyond your team.

Step 3: Make sure your code adheres to best-practice naming and formatting

  • You’ll want your open-source code to be examples of your best work. Make sure you are using good, standardized naming conventions and formatting. Use tools like pyflakes/pep8, jslint, gofmt, ReSharper and others to help.
  • Also, keep in mind that if you’ve been wanting to do the One True Naming Standardization for your project, now’s a good time. Once you open-source your code, there will be a lot of inertia to avoid breaking changes. Get those done before you release. It’ll also make it easier for other contributors to get started with your code.

Step 4: Document it

  • You don’t have to write ninety pages of info docs but you should at least have a nice Markdown-formatted README.md in your root directory that explains what your software is, how to use it, and (if applicable) how to build it.
  • If you’re releasing a library, you should also make sure your code has docstrings/JavaDoc/whatever so that you can generate API documentation.

Step 5: License your code

  • You may want to get some proper legal advice on this. But before releasing your code, you should pick a license. Unless you have a compelling reason to do otherwise, the MIT license will probably suffice. It’s short, sweet, well-understood, liberal and makes integrating third-party changes back into your own products headache-free. But if you’re contributing to the code that you want to include in a project that already has its own license, you might want to use that license instead. Here’s a useful overview of license types for more info.
  • You’ll want to put a LICENSE file in your repository and have a copyright notice somewhere prominent — either in that file or in the README. Such as ‘(C) 20XX Your Name. All rights reserved.’

Step 6: Name your library or tool

  • Pick a name. Make sure it’s not offensive and avoids having the same name with other existing libraries and trademarked products.

Step 7: Push your code

  • Put it on GitHub, create your own organization, repository and push your code.
  • Keep in mind that some communities have secondary systems that you should consider utilizing as well. If you’re writing .NET, then another one might be Codeplex. If it’s Ubuntu-specific then a Bazaar mirror on Launchpad etc.

Step 8: Publish your package in the appropriate package archive

  • If you’re publishing a library, submit it to the appropriate package manager. For .NET, that would be NuGet; for Python, it’s PyPI; for Perl, it’s CPAN; for Ruby, it’s RubyGems; for Node, it’s NPM; and so on. Also, make sure that someone else at your company, such as a sysadmin, has the ability to continue maintaining the library under the unfortunate circumstance that you get hit by a bus.

Step 9: Announce your code

  • You’re all good, time to announce it! You’ll want to blog and tweet it out. You should also consider publishing on /programming on Reddit and Hacker News etc.

And that’s it! You’re all done!

…well, nearly.

Step 10: Don’t forget about your code

  • Just because you’ve published it doesn’t mean you’re done. You’ve unleashed a new-born into the world; you need to take care of it. Monitor pull requests and bug reports on your new project. If you realize that keeping your project going is overwhelming, then a hearty congratulations! You should remember that it is your responsibility to at least find an extra or substitute maintainer. It’s okay if your project ultimately forks but it’s best not to do so just because you dropped the ball incorporating freely and submitted improvements to your code.

That’s it. For real this time. So go out, contribute, and have fun!

How to Organize a Hackathon?

So you want to run your own Hackathon? Great! Hackathons are a good way to meet and exchange ideas with fellow developers and creative team. They provide attendees with a boot camp style of learning and making something in just a few hours or days. They also push people out of their comfort zones so it can be a great method of getting people to work on different projects or with new technologies and programming languages. However, these events take a significant amount of planning and preparation in order to be successful. We’ve run many similar events for developers over the years and here are our tips for organizing your own Hackathon:

Pick An Inspiring Theme

There are plenty of events for developers. Pick an interesting theme for your Hackathon to help your event stand out and improve attendance.

It could be a community event based around a specific language or tool. A corporate event for an API or product. Perhaps an internal event to encourage innovation (Facebook’s Like button was first demoed at their own internal Hackathon). Or maybe one based around some special interest topic, such as a charitable cause or a hot topic. Whatever it is, it’s worth investing the time to come up with a creative spin that sets it apart from the others.

Set Event Goals and Define Success

Having a clear idea of what you want to get out of your event will allow you to focus on what matters. You might define success with the number of attendees, submissions or press mentions but identify your conversion criteria upfront to simplify the planning process.

Work Out Who You Need to Involve

Knowing your goals will help you begin to understand the scale of your event and what you need to focus on. If it’s maximizing the attendees, then you’ll want to go big. Big often means expensive and you may want to get sponsors involved to cover some of the costs if not all. If the Hackathon has a competitive edge, then that means hosting judges on duty. Maximizing submissions? Then you might want to think about offering prizes. Doing it for the coverage? Then start reaching out to your media contacts early.

Hackathons also have a lot of tiny details need to be taken care of and often all at the same time. Since you can only be in one place at once, you’re going to need assistance. You’ll need an MC to keep things organized and the event flowing. Then there are reception people in front of the doors to get attendees registered. To get the most value out of your event, you should consider recording it and taking lots of pictures so perhaps a photographer or at least a friend/colleague or two. You know the ones with the fancy cameras that they carry with them everywhere they go? If you’re doing demos, then you’ll also need people to help with the A/V equipment and be on hand to offer tech support. Make assisting people clear and visible on the day of the event with colored t-shirts.

Choose a Date and Time That Works

You need to pick a date and time that will work for your crowd. Make sure you spare enough time to plan it all and consider the day of the week that will maximize the attendance.

For work-based Hackathons around a product or service, weekday events are OK. You’ll need to provide long enough notice for attendees to get approval for the time out of the office. Also, stick to typical office hours like 9 to 5. For other types of events, weekends are better, especially for longer events. Weekday evenings, straight after work, can work well for shorter events – just remember to keep the drinks flowing.

Before you settle on your date, check out event sites like Eventbrite, Meetup and Lanyrd to rule out clashes with other events. Starting 8-10 weeks in advance is usually about right and remember to at least send out a ‘save the date’ blog post or mail once you’ve picked it.

Find An Awesome Venue

This will probably be your biggest expense but it’s not where you want to try to save money. Location can be a key factor for attendees when deciding whether to come or not. It needs to be a convenient location with easy parking, big enough for all the attendees and have the facilities to support them. That means enough space, WiFi and power. If your event runs overnight, then you’ll also need accommodation for people, blankets, stuff to lie on and maybe showers.

Make it as easy as possible for people to get there. Provide comprehensive directions, maps and transportation details. Don’t forget to spell out what to do once they get there too – signing up at the reception, how to get through the security and more. Print big signs to guide people.

Get the Kit

You’ll need A/V equipment like projectors for simultaneous sessions and microphone for slides and demos of applications. Make sure to test it ahead of time. The first time you set it up shouldn’t be the day of the Hackathon.

It’s often easier for attendees to present on their own hardware. Yet, you need to allow a quick turnaround between presenters. To save some time, have a couple of stations connected to the projector ready. This way, while one team is presenting, the next one can be set up.

If you’re filming the event, and you should, then, you need camera equipment. Unless it’s going to be a regular thing, you may want to hire the equipment or a photographer/videographer who already has it.

Get your swag on. Have a bunch of t-shirts available for giveaways and thank yous. Whatever design you come up with, make sure it doesn’t have a date on it. If it does, that means you can’t re-use any leftovers later on.

Have plenty of spare cables, USB drives, socket adapters and extenders available. Cover all connection types – Thunderbolt, DisplayPort, VGA etc.

Have Killer WiFi

This is super important but like at many hotels, WiFi sucks at a surprising number of event venues. Check this out before deciding on the venue and make sure the venue knows how important this is for you. Better yet, pick a venue where the WiFi has been thoroughly battle-tested by previous dev-related events. Make sure the venue has plenty of power sockets too. You want approximately 1.5 per attendee to cover all the laptops, tablets, phones and personal electronic devices.

Get More Than Enough Food and Drink

Don’t skimp on the food and drink. Nothing sends people home quicker than being hungry or thirsty. Have a large variety – it can’t be all Red Bulls and Oreos. So include soft drinks, tea, coffee, water and juice to your drink menu. Arrange breakfast, lunch and dinner. Have snacks available whenever people want them and include both healthy and junk food options. No matter what you do, don’t run out! If necessary, make trips to the local shops if you’re getting short during the event. You always want to end up with too much than risk having too little.

Communicate About the Event Regularly

Blog regularly before and after the event. Hit up any press contacts and influencers that you know to spread the word on Twitter and other channels. Keep in regular contact with your prospect registrants – once people know about it, you want to make sure it stays on their radar. To help you with this communication, set up a dedicated mailing list. Drip out information like venue confirmation, sponsors, judges and guests. Remember to follow up after the event as this is a good way to keep the mailing list fresh and ready for your next event.

You also want to set up a dedicated web page or site for the event which collects all the key data (date, location etc). For registration, don’t re-invent the wheel, just use Eventbrite, Meetup or similar.

Have Fun

Once it’s all over, remember that it was, in fact, a ton of fun and start prepping for the next one.

 

7 Tips For Better Developer Designer Relations

In typical organizational groupings, designers and developers often find themselves in separate teams. Also, a common misperception of the people in these roles is that they are different — developers are logical, analytical, left-brainers whilst designers are the creative, flexible, right-brainers. And whenever people are separated like this, it’s easy for the relationship to become adversarial. Pretty soon all you do is to focus on the differences. Either they are those hippy-dippy designers with their strange and impossible requests or those vision-less, code monkeys. An ‘Us vs. Them’ mindset takes hold, leading to a break-down in communication which gets borne out in poorer products.

But does it need to be like this? I mean, there’s a lot of common ground. Both have a keen eye for detail, solve problems in creative ways and often share a love of great tools and technology. What’s more, the theory around what you can do to overcome these issues is simple. You just improve communication, empathize with the other team, respect to their contributions and build trust. Yet, actually achieving that can be tricky.

So, here’s seven practical things you can do to help designers and developers work better together:

1. Mind the Pet-Peeves

Developers:

  • Be Clear About What You Want

Often it seems that designers are expected to be mind readers. The brief for designers can be a little more than “go make this look good.” It’s just how a developer might ask for a requirements specification, a clear brief for a designer is also important. Make sure to provide examples of what you need. These might just be links to how others have approached a similar thing or even a quick sketch.

  • Be Mindful of Design Constraints

If you’re working with data, then supply real samples if possible. Knowing the data ranges you’re trapping in your code can be useful for designers to know too. Designers also need to know things like screen sizes and browser compatibility from the start.

  • Be Open About What’s Achievable

Developers can be the gatekeepers of what gets implemented. A big idea can all too often be dismissed out of hand in the name of time or performance constraints. Often though there’s a compromise to be made, with some part of the original idea being possible. So staying open-minded and working with the designer to find that compromise is important.

Designers:

  • Make Your Assets Easy to Work With

Name different file versions so that the latest version or the one you want to be used is easily found. Maintain the layers in image assets, naming them usefully and grouping them whenever you can. Don’t forget to also remove any old and no longer needed layers and files. If possible, prepare the assets for use too — cut them up so that they can be used straight away.

  • List Out Key Details

List out the names of fonts, text sizes and hex color codes used, along with the widths, heights, padding and margins you’re expecting. Doing this can be a real time-saver for developers.

With those pet peeves eradicated, you can start to focus on processes and ways of working.

2. Work Closely Together

This can be just having designers and developers sit next to or near each other. This helps encourage short, informal conversations that lead to more open and frequent communication. But this can also be applied remotely too with regular video chats and Instant Messenger or Group Chat. Either way, if you do this, then over time you’ll absorb knowledge about each others work.

3. Start Communication Early, Continue Regularly

It’s best to start a communication between the two teams as soon as possible into a project. If you build it into your process right from ideation, then there are no surprises that can cause problems later. So start off with designers and developers working together on how they can approach the project. Then continue the communication right throughout the build too. Look for opportunities to keep each other up to date on progress and developments. So, for example, when working on wireframes, designers can involve developers in deciding how to work with different screen sizes, devices, and browsers. Designers can share sketches, and likewise, developers can share links to works in progress. At all stages, bounce ideas off of each other, not just your own team, and break out onto whiteboards when you need to work through a problem.

4. Pair Designers and Developers

When the chance to work together doesn’t emerge itself, you should actively encourage it with the designer-developer pairing. For example, as Cap Watkins recommended in our recent interview, designers and developers can work together on a design bug rotation. This is where designers and developers pair up to work through a list of design issues. This involves discussing the problems, deciding on solutions and fixing them together. By doing this, designers are given insight into the code and developers are exposed to design-related issues.

5. Open Up Design Critiques

Opening up design critiques to others is a great way of helping them to better understand design work. This is something we’ve started doing at Fog Creek. We’ve seen that by showing example work and then walking through the design rationale, non-designers can better appreciate design issues. What’s more, describing how you’ve considered implementation issues shows that you’re taking developer problems seriously.

6. Run Designer and Developer Placements

For example, Etsy runs an engineering placement program. This program aims to get employees with no technical knowledge in deploying simple code changes in a few hours. Spending time working with other teams, even for a short time, helps to foster cross-team communication. This can be taken further too, with embedded team members, so designers embedded in development teams and vice-versa. Trish Khoo explained how this works with embedded test specialists at Google, in an interview with us.

7. Learn about Design or Development

Knowing even a little about code will make you a better designer. It’ll help you to understand and resolve implementation issues that you would otherwise have run into later. Similarly, some understanding of the theory and processes involved in design work will enable you to provide more useful feedback. Learning about design does not mean you have to be creating design assets. And the same goes for the code too. But by at least knowing the terminology and key concepts, you’ll be able to have more meaningful conversations about design and code issues.

By thinking through and creating opportunities for designers and developers to work on issues together, you can encourage a closer and better working relationship.

Why Your Retrospectives Have Become Unproductive?

Retrospectives provide teams with an opportunity to reflect. They’re an opportunity to discuss what is working and what isn’t with the goal of iterative improvement. The meetings should create a safe environment for team members to share and discuss processes and practices constructively so they could come up with actions to resolve problems or improve how the development team functions.

Yet, often this isn’t the case — retrospectives break down, become unproductive or just don’t happen at all.

Here are 3 core failings with retrospectives, along with potential causes and remedies:

1. Retrospectives That Don’t Lead to Real Change

The desire for continuous improvement is at the heart of retrospectives. The feedback gathered during the meetings should result in action items. These action items, upon completion, should deliver positive change. But if the action items aren’t completed or the true cause of problems is not identified, then the faith in the process can wane.

This can come about for a few reasons:

  • Too many action items

It’s important that you don’t try and tackle too much and fail to make real progress with any of them.

  • Items are vague or have no clear resolution

The action items you create need to be specific and have a definitive end point. Items like ‘improve test coverage’ or ‘spend more time refactoring’ lack specificity and need to be quantified. Concrete action items provide demonstrable results — allowing the team to see and feel the improvements achieved by following the process.

  • A lack of responsibility for actioning items

Often the facilitator can end up with all the issues or items are assigned to groups of people. This is a mistake — each item should have a dedicated owner who is in charge of ensuring to get it done, even if a team would be completing them.

  • Too much emphasis on technical issues

Working with tech is what we do so identifying problems about systems, servers, libraries and tooling are easy. But you need to ensure that you give just as much attention to working practices, communication, and people problems. Otherwise, these key impediments to improvement will hold you back.

Whatever the reason is, it’s important that you’re completing the action items. So prioritize them and focus on just a handful of items that you know can be done before the next retrospective. Break down larger issues so that you can begin to make progress with them too. Track items raised at previous retrospectives and review results in each session. This sense of momentum helps to build and maintain a belief in the process and fuel future improvements.

2. Retrospectives That Don’t Occur Often Enough

If retrospectives don’t happen often enough, it can cause a number of knock-on effects:

  • Too much to go over in any one retrospective

This results in meetings that fail to get to the cause of issues. Or due time isn’t spent on issues important to attendees, which can be disheartening.

So much has changed since the items were identified that the issues raised are no longer a priority. This doesn’t mean they aren’t important. More often, it just means you’re compounding them with others and you’re missing an opportunity to improve.

3. Lack of Participation in Retrospectives

This can often happen if the meetings aren’t managed effectively:

  • Sessions are long-winded

You should decide on the agenda before the meeting to avoid straying off the topic and unfocused discussion. You might want to consider time-boxing sections of the meeting. This helps to ensure discussion on one section or type of problem doesn’t consume all available time and attention, and that all areas get adequate attention.

  • Sessions have become stale

Change things up. Try removing seating for one session, so people don’t just sit back and switch off mentally. Or change the format so you aren’t just repeating the same old questions. There are plenty of different techniques: from the Starfish and 4Ls to FMEA if you decide to deep-dive on a specific issue. Or just pair off and discuss items to bring back to the group. Some people open up better in smaller groups. And one-to-one force a conversation, otherwise, things get awkward.

  • There’s a lack of trust

A lack of participation can also result from a breakdown in trust. You should only invite team members to take part. Observers, especially management, despite noble reasons for attending, should be dissuaded from doing so. It may seem to make sense to share feedback so that other teams can learn from it too. But the specifics should be kept in the room. People might not contribute if they know there will be a long-term record of it, or if attributable comments are shared. Just share the action items or areas you’re looking to improve.

  • Sessions are too negative

Retrospectives should encourage introspection and improvement. But this doesn’t mean it’s just a time to moan. It can be too easy to focus on the things that aren’t working or you failed to do. So it’s important to make an effort to highlight improvements, and not just from the last iteration but over time too.

With a few changes and a renewed commitment to the process, retrospectives can be a great way of ensuring you’re constantly improving. They can be an important part in making the working lives of your developers better and more productive.

Older posts