Ok, so you’ve got a small technology company and you’ve hit that threshold of about 4 people where it becomes glaringly obvious that you need to institute some process. Or perhaps your engineering team is smaller than that, but you realize that if you don’t spent at least a minimal amount of time on planning your work, you’re going to spend a lot more time doing the wrong work, the less important work, or delivering the wrong thing.
This article will help you bootstrap some minimal processes that will enable you to be much more effective. It should be enough to carry you to the point that you have to split engineering into multiple groups at about 10-20 people.
- Get Buy In for 5%
The first step is to discuss with the team the need for some minimal process. You’ll be surprised how easy this is, engineers like process because they like algorithms and they like solving problems but they hate rules. The key to all process is to make it organic and flexible which means getting buy in first that you’re going to need some process. At this point, get your team to agree to a time budget of 5%, then have them do the math and realize that means 2 hours week out of a 40 hour week. Those 2 hours/week are yours to spend.
Why: You’re going to spend more than this if you don’t devote time to being organized. Getting people to buy in and setting a boundary is a perfect start to planning anything, this is no exception.
- Institute Pierce’s Check In process.
This is something they do for 10 minutes/day as part of their 5%, or 50 minutes a week. Now you know why you needed to get buy in for 2 hours. You’ve spent 50 minutes already!
2a. You start the day with an empty email titled: [CI] Pierce 08/02/2013
2b. Throughout the day, use that email as a work log. Did this, did that, this sucked, this was awesome. Make jokes! Bitch (but not about people in your company).
2c. At the end of the day, add a summary section to the top with the highlights.
2d. Send to all of your teammates or people you worked with on problems.
Why: It will actually be interesting to know what everyone is working on, and it will solve problems practically before they happen. That is, all process is really about communication. If you start the habit of having everyone on the team communicate with each other every day, you’re building a rock solid foundation for your entire company.
I do this every day, and send it to everyone relevant from my CI every day. Everyone reads them and knows what’s going on with me and my group. Its funny because people don’t like writing their CI, but they love reading other people’s.
Additional Manager-Fu is that its inescapable that I end up reviewing my day at the end of the day, and I can easily review my previous day and quickly catch anything I need to do today when I start my day. Besides writing stuff down, a key feature of all of the Time Management systems out there is reviewing your day.
- If you don’t have a manager, Designate a Process Person.
Background on why the best technical person doesn’t have to be the process person.
Normally, its the managers job to oversee the process. But this doesn’t have to be a management role, this can be a “followup and through” role because ultimately, its about making sure people are following through on the processes that make everyones life easier. In the Navy, the lowest ranking person on the ship was often in charge of morale.
Why: Someone has to follow through and up, otherwise everyone assumes someone else will do it.
- Project Charters
When you first started your company, it was obvious what you needed to do next, even if it was only order lunch. At some point though, you start to have multiple projects jostling for your time at all time. Everyone always does! But if your company is now at the point that you’re willing to read a blog post about good engineering processes, its time to institute project charters. Project Charters are simply a way of articulating clearly why you’re doing a project so that you can choose the correct projects to start first, so you know when a project is complete, and so you can communicate with your team and others about a project.
Why: The most important thing to know on anything you do is why you’re doing it, and what your barriers to success are.
Project Charters are simple to create. They are just a 1 page document you spend an hour on so you know why you’re doing the project before you start it. If it takes more than an hour to write a project charter you had to talk to people you needed to talk to anyways. You’ll see some immediate victories for process here:
- Any project you choose not to start immediately because of some other more pressing project is a double win in terms of time and resources that both didn’t get spent on the less important project, and in terms of the same time and resources that you got to spend on the project that did win instead. It’s a two-fer-one.
- If writing the charter forces you to talk to some other people in your company to figure out why you’re doing a project, imagine how much worse it would have been to start off in the wrong direction and flounder about figuring out what you needed to do? Haven’t you been on one of those projects? Didn’t it suck?
- The project charter will enable you to stop early. Taking a project past its success criteria is going to consume resources you could spend on other projects. You don’t need to gild the lily.
A project charter should have the following short sections:
Vision: Why are we doing this?
Driver: Why are we doing this now or what’s the most important thing that has to get done?
Constraints and Floats: (Deadlines, resources, features, quality, what are we stuck with and what is flexible?)
Success Criteria: What does this project have to accomplish to be successful?
Stretch Goals: What would be nice if this project accomplished?
ROI (if appropriate): What will the company/engineering department gain if this project is completed?
See Manage It by Johanna Rothman for details on how to manage the process or you can read up on “Context Free Questions” for help. Note that I’m not advocating a formal requirements process, I’m advocating the only page of the requirements document anyone ever reads anyways, the part that says “what this project is about”.
- Manage your operational bandwidth vs. your development bandwidth. Choose appropriately.
Everyone has both operational tasks that tend to be interrupts, and development tasks where they need focus. Figure out some way to keep the operational load from overwhelming your development load. I do this by attempting to throttle the amount of time people spend on the operational functions either by slicing people’s time (including my own), or by allocating operational duties across people and rotating people into the hot seat.
Why: Customers are wonderful because they give you $. They also give you problems. If you don’t manage the interrupts, you can’t get the development done you need to get done to prevent the problems, which makes the problems worse, so you spend more time on them… Get in front of the problems, and life is easier. You don’t have to implement this process immediately, but monitor the time you spend on operational problems over development problems and keep the levels appropriate.
Manager Fu: It’s better to interrupt engineers before they start for the day, before the break for lunch, right after lunch, or at the end of the day. Anything else destroys their focus. Schedule your meetings appropriately when you can, and if you’re a manager, think about when you’re going to interrupt your people for a question.
- Try to only shoot yourself in the foot once with Post Mortems
After you shoot yourself in the foot, write up a project charter for how to prevent it. Doesn’t mean you’re committing to do it, you’ll have to juggle that project with all the other projects. My rule of thumb is that you always have 20-30 things you could be doing, and resources/time/focus to do 3… But writing down the ROI and costs will make you aware and feed into future planning. This can be the output of a Post Mortem meeting where you discuss what went right and what went wrong. Work hard to avoid blame in that meeting.
Manager Fu: Focus on what’s right, people tend to focus on what’s wrong, but often the wrong is a side effect of the right that you have to live with. If the wrong isn’t a side effect of the right, prioritize that you should do more of the things that went well. That’s Manager-Fu because its easier to do more of the good things often than less of the bad things and definitely more fun.
- Process is best when organic, evolving, and flexible.
Your processes are going to work best when you grow them to match an existing need. Remember that and have a regular process to review your processes and tweak them. The processes that make sense at 4 people may not make sense at 6, 12, or 60. The process you institute your first week won’t be the same process you have at week 10, 20, or 52. Grow, adapt, change and throw away.
You can find Johanna Rothman’s book on Amazon: