The Journey Continues
Originally published Thursday, July 19, 2012
The trend continues – I seem to enjoy piling life changes on top of one another. In an effort to maximize my stress, in the forty days I’ve purchased a house, moved, and changed jobs. So far so good.
That’s right… I am now employed by Pharos Systems, a great local company. There are two main reasons I’m excited about it: One, I have a history with several of the people that I’m now working with, and Two, I’m working on a product again.
In the ancient times, right out of college I was employed by a company called AHT, which was an acronym for “Advanced Hi-Tech” (I didn’t come up with the name). Sadly, that company folded in the wake of the post-9/11 recession. Although I had to find a new path, several employees and managers from that firm went on to form a company called Ten Technologies, which was later acquired by Pharos.
Several years later Pharos had a need for web developers, and some of the AHT folks remembered me and gave me a call. I was thrilled about the opportunity to reconnect with some former colleagues, and a few interviews later I was on board.
A Real Product
While I can’t be too specific on my actual project, I can say that I’m back on a product team for real. It’s marvelous. I’m on (what’s currently) a two-man team, in a larger project group that includes three other development teams of 4-5 people each. The project is headed up by a Product Manager and Director that have long-standing engineering backgrounds.
We’re in a basic Agile methodology. Two-week sprints, with several stories planned for completion. Each morning we have a daily stand up to go over what we’re doing for the day.
The best thing is that we are more or less in control of the sprints – the project has an overall time frame and backlog, with multiple stops along the way that have criteria that must be met, but in terms of the sprint planning, we can agree with management about what bites we can take.
At the risk of going into a rant, there are a lot of lessons that any employer can learn from the engineering practices at a company like Pharos. I’ve been involved in different internal development groups in my career. While they’ve had very talented people in them, they were either mismanaged (if their directors had no project experience), or underutilized (if leadership didn’t understand their function).
So here are some basic things to remember if your organization does any development at all:
- Development of a web application or a web site is a project, not a task. Even if it’s supportive of a larger initiative, for example a web reference library or news system for an institutional project. The development of the site/application takes time and effort, management, and dedication from all the people involved. I’ve been in meetings where someone actually says “We can put up all this information on a website” and everyone expected that to be the end of it.
- Development takes a team of people, not just one employee. In my first month at Pharos, there was more progress made on a single web app than I’d seen in four years in other places. Why? Because no one threw it to a single developer, saying “You’re now the beginning, middle, and end of this project. Go make the customer happy.” There’s two developers working on it, with a dedicated product manager, and a director who has this project at the top of his priorities. Which relates to my next point…
- The team can work on one project at a time. That’s the simple truth, but it can be difficult to admit. I remember, in ages past, sitting in a room with a manager going over a list of several dozen active projects—that grew larger every day. Not surprisingly, none of them ever made any progress. Ever. The culprit here is an inability to say no, or an assumption that any proposed project is an accepted and finalized project. The #1 job of a manager in charge of developers (in my opinion obviously) is to prevent this situation.
- All technical decisions need to be controlled by the team. In my current role, the individual teams all have input into the decisions about project standards. But it’s quite clear that a team in different project group can’t suddenly throw in some new technical requirement—they are welcome to make suggestions, of course, but ultimately our director handles the scope of the project, and he’s entrusted with keeping it on track. Which brings me to…
- There can be one team on the project, with clear management structure. I’ve seen situations where a project is going along nicely, then another group introduces a developer into the mix. He or she says, “this is all very nice, but my experience is all with Joomla and PHP, not Umbraco and .NET.” What follows is a whole new round of platform discussion, trying to determine who’s really in charge of the project. The project implodes, and in the worst cases, the entire development team can be marginalized to merely platform administrators for the other group’s single developer.
If I were a “consultant” I’d make this blanket warning statement: If your organization can’t commit to all five of these criteria, don’t do any development. At all. If you try, you’re going to have a team of miserable people, who can’t deliver anything, and get a very poor reputation. Use service vendors instead, project-by-project. It will really be best for everyone in the long run.