This is part two in my ‘Vistaprint Lessons Learned’ series. I only have four lessons this time, but I think they’re important. I’m sure I learned more than just four lessons about working efficiently, but also these lessons are more about continual improvement than many of the software development lessons were. Therefore, I’ve spent a lot of time on each of these lessons, and I’m sure I”ll continue to spend a lot more time on them in the future.
Don’t be bashful – you have to advertise yourself to be recognized
One of the best things that I did when I was at Vistaprint was to write some really thoughtful articles on the internal wiki while working on one of my early projects. I didn’t even necessarily mean for people other than my partner to see it, since it was just a good place to collect notes. However, other people did see the work I was doing and offered me an opportunity to move to the studio team where the sort of stuff I was thinking about was very important. This was exactly what I wanted to do, because studio looked like it had some of the most interesting technology at Vistaprint. If I hadn’t put up public wiki articles, would I have ever had the chance to move to the team I wanted to and on which I would eventually become a leader? Who knows?
Organization is crucial
That organization is important shouldn’t really be a surprise to anyone, but I did get a lot better at it during my time at Vistaprint. When I first started, I had just come from school and had never led a really large project that required many undefined steps and didn’t necessarily have a clear end date before. At Vistaprint, I worked on larger and larger projects and eventually had to drive requirements, tech design, etc. The smoothest projects had plans upfront and I spent enough time to go through the larger architecture before starting. I’ve gotten much better at driving things to completion on my own – breaking them into manageable pieces, picking where to start, and knowing when they’re complete. At Vistaprint, I was constantly involved in many projects at one time and wouldn’t have been able to finish all my work without being organized.
To keep track of projects, we used the Jira ticket management system, which was pretty good overall. However, if you just use it in its default state, tasks can still be too coarse to plan with and follow through on. I developed lots of tricks for staying on top of the actual individual tasks that needed to be done and recording results. For an example of recording results, I noticed early on that I’d often want to go back and review the SQL that had been run while finishing a Jira ticket, but since SQL wasn’t tracked in subversion, I couldn’t find it. Therefore, I made a habit of always pasting any SQL that I executed into comments on the jira ticket. In order to keep track of individual tasks, I took a lot of tips from GTD and made sure I always knew what my next actions were so that I wouldn’t have to continually spend time deciding what to do. Finally, I also had to have reminders even for other people’s tasks if I was waiting on them. Everyone has good intentions, but people don’t realize that they’re holding someone up or that a task is important unless they’re told, so periodic nudges are necessary.
To be a good leader, you have to help your team produce good work
Further into my Vistaprint career, I had to organize a number of coworkers for a few projects. The first big project I worked on was actually very tough. I was fine managing my own work, but became a bit overwhelmed when trying to manage other people’s work as well. I spent a lot of time at the beginning figuring out who should do what and making sure we all had assigned parts, but I didn’t spend enough time after that following up and making sure that the code everyone was writing was really good. As my manager, Osi, but it, when you’re a leader, you can’t just make sure your work is done well, you need to make sure the team’s work is done well.
I think my trouble came down to two underlying reasons. The first is that I didn’t offer enough feedback. I let myself get a bit overwhelmed by my own work and didn’t budget enough time for design reviews, etc. Another aspect is that even when I did get a chance to go over my coworker’s work with them, I wasn’t strong enough in my feedback. I can think of two or three pieces of code in particular that I could tell were going to be difficult to maintain and hard to prove correct. However, it seemed to be working, so I didn’t make the developer clean it up – instead, I said that it could be improved and that I would have done it differently, but that we’d leave it so we could keep moving forward. I also didn’t take the time to specifically analyze everything that was wrong, so I don’t even know that the feedback I gave would help my coworkers to not make the same mistakes again.
The projects after that one turned out better, but I still need to improve, and helping a team perform really good work as a whole is something I am going to work on a lot while starting Bespoke Row.
No surprises == no problems
That’s not strictly true, but it’s close enough to be a lesson. Communicating project status with everyone on the team helps everyone know what’s going on and helps adjustments to delays or other problems happen early. Communication isn’t just telling people what you’re doing, though, it’s also listening to what they say.
I worked on a range of projects at Vistaprint that all had different status update styles. In some projects, we didn’t really talk much until the show-me right before launch; if there were any problems, they were surprises to management and immediately urgent issues. In other projects, we had to report status every day and the team constantly adjusted the schedule, moved requirements around, and prioritized in order to make sure we still got as much benefit from our work as possible. In still other projects, we reported status frequently, but no adjustments were ever made, so we just ran into the same problems knowingly…
It’s possible to go too far and have the process end up taking away more time than it saves, but it’s easy for status updates to be quick and simple so they only take up more time when there’s an issue to be addressed.
This lesson is mostly written from a team perspective, but it’s important individually, too. Even if your team doesn’t do status updates, etc., it’s important to keep your manager aware of what and how you’re doing. They can help keep you from doing unnecessary work, and if you’re having problems, they’re much more likely to understand when something isn’t done perfectly or on time than if you just tell them on the due date that your project isn’t done.
