SWOGC: How We Built a Web Portal in under 48 Hours

Southwest Ohio Give CampThis past weekend I volunteered my time to the Southwest Ohio Give Camp for the 3rd consecutive year. All in all, it’s a great event, a local chapter of GiveCamp.org, where regional software developers, designers, and technologists gather together in teams to create working solutions for charities. In the past, I’ve merely volunteered my time and expertise, but this year I undertook a higher challenge, leading my own team. In this post, I discuss my plan for building an entire web portal in less than 48 hours and the lessons learned.

 

Leading a GiveCamp Team – The Plan

I had compiled 8 tips for myself through observation in past years. Going into the weekend, these were my keys to success:

Before the Weekend

  • Prepare with the charity representative to obtain the majority of requirements
  • Present the charity with a “Wish List”, what we need the charity to provide (e.g. logins or files) to be successful
  • Begin visual design collaboration and discussing philosophies
  • Decide on a CMS, such as WordPress or Umbraco

During the Weekend

  • Be pragmatic and cognizant of the critical path!
  • As leader, make sure there are no tasks during the weekend that only I can do
  • Stay clean and flexible
  • Create a project plan first

 

Putting it all together – The Execution

Knowing I would be leading my own team, I recruited 2 .NET developers to help over the weekend. In addition, the event organizers assigned me 2 more developers and a designer. Our charity’s representative was also there to help for almost the entire time.

From Friday evening to Sunday afternoon, our team of technologists contributed about 120 hours to the project. We implemented an internal employee portal for the charity made to match the style of the existing website as much as possible. I would say it was generally a success.

 

Lessons Learned – a Retrospective

“Is that it? That’s all you’re going to say about how the weekend went?”

Well, the details of the project weren’t that interesting. But now that you know what happened, I can remark on what I found to be most important about our strategy and implementation.

Getting Started was Difficult

As you might imagine, assembling a team of mostly strangers, who know very little about the task at hand, can present a specific set of problems. Namely, everyone struggles to dive into a task because of a lack of knowledge about the overall requirements, plan, and others’ skill sets while pitted against the aggressive time constraint.

I think this is somewhat unavoidable. I did a good job of following my own advice, numbers 4 and 8 from above. I also had a list of known tasks pre-written on post-it notes that I used as discussion points to explain the scope of the project. I think having had some of the bigger decisions made going into the weekend helped the team to focus on delivering value to the charity. However, the team didn’t seem to naturally mesh and become fully engaged until Saturday afternoon.

How could I have changed my approach to reach that point earlier? I could have gone further with my research for the weekend making sure that any technical roadblocks were overcome before we started. This became most obvious in relation to my choice of CMS. We were using Joomla!, the CMS that the charity already had for their existing website. Personally, I did not know enough about this CMS to get started in a reasonable timeframe. I was dependent on team members to get our site up and running and the members who did not know Joomla! did not have much to do. Looking back, I would either choose a CMS that I was already more comfortable with or make sure that I knew how to get started with what I chose. Alas, I realized I got lucky with my team member assignments by acquiring some Joomla! knowledge along with them.

Iteration is Awesome

Having the luxury of a charity representative throughout the weekend, we leveraged a tight feedback loop to ensure we delivered a valuable solution. In fact, around noon on Saturday, we all realized that a significant portion of the planned tasks would only be of marginal benefit. Because we adhered to tip number 7 above, we were able to have an ad hoc discussion with the charity about what would provide the most value. As a result, we scrapped many of the broad functionality on our project plan and replaced it with one deeply functional requirement. Had we not had an iterative approach we would not have been able to fulfill the charity’s actual needs.

Get a Designer

Every year, the most in-demand skill at these GiveCamps has been design. There are usually not enough designers for every team and this year was no different. We were lucky to get assigned one (who also was fairly knowledgeable in Joomla!). Having a designer on the team is important because there is no easier way to feel like your solution is worthless than to have it look subpar. This is especially true at a GiveCamp weekend, when all the teams present their results on Sunday and give you benchmarks to compare against. On a time constraint and non-existent budget, I don’t know many developers who could make a user-interface that meets the new standards of the web. Even though our charity was not looking for a “fresh” design on their internal portal, it was nice to have someone who could troubleshoot display issues as we put it together.

 

Would I Do it again?

In a word, absolutely. While I’ve found that the solutions created for these charities over the past 3 years have not been the most interesting technically, the delight and value we are able to provide for non-profit organizations is quite fulfilling. Sure, the weekend comes with a certain level of anxiety. At one point on Saturday, the Web Host for the charity’s site (and all our work in progress) went down temporarily rendering our team useless. Still, it is a great way to meet other local developers who do not necessarily work on the same platform in their day jobs. Leading a team of volunteers who just want to contribute their skills in the most effective way possible provides exactly the right amount of eustress, and I’d recommend it to anyone.

Advertisement

I invite you to connect, but only on your own time

This blog post is the 3rd and final of a series of Anti-Pattern stories

In this last post of the series, I finally take the opportunity to rant a bit. Thinking back to the time when I worked at the aforementioned small company, I realize the reason I became so emotionally affected was because the company seemingly had great growth potential that never materialized. Below is one last story of workplace theatrics accompanied by quotes from my favorite movie of the last 5 years, Forgetting Sarah Marshall.

“Do Less… Well no, you gotta to do more than that”

One of my favorite lines from the movie applies to the network monitoring policy at this corporation. For at least some period of time, the paranoia from above was deep, resulting in a robust monitoring software rollout. Whereas some companies track proxy statistics to determine broadband usage and lists of sites visited by employees (a tactic I have no problem with), that was just the beginning in our case. Here, all corporate emails from most employees were published on the network to keep them honest. Additionally, the owner of the company installed software to be able to view keystrokes and screenshots from each employee’s computer usage on the network. Details about this product’s existence as well as the tracking information collected were only supposed to be accessible to the owner. When a Network Admin noticed a peculiar “SpyWare” program on the server, the “cat was let out of the bag”. In retrospect, we all should have had some suspicions based on the broad statement allowing company collection of data in the Employee Handbook.

Knowledge of keystroke logging was held in a fairly close circle, shielded from new employees. Therefore, I did not find out about it right away. Granted, I do not like the idea of anyone being allowed to track keystrokes, as that provides all the information needed to login as me on the network and possibly additional websites, etc. However, the network monitoring policy that frustrated me the most began when “questionable” sites became blocked, inaccessible to users on the network. Some of the obvious sites you would think of were on the list of blocked sites (Gaming, Personal Email, MySpace) but also blocked were those not so obvious sites (Personal Banking, LinkedIn, YouTube, Random Blogs). Many times during the day I would be blocked from information on the Internet I needed to do my job, such as tutorial videos on YouTube or programming help on a blog. The “straw that broke the camel’s back” for me was when I received a LinkedIn Connection request from the owner, but I was not allowed to accept it while on the company network. How can the site be considered valuable and reputable enough for the owner to use it to connect to employees during work hours but not reputable enough to actually allow them to reciprocate while on the job? It was as if we were being asked to “Do Less.”

“So then do something about it”

If working at this place was so dreadful, why did I continue to work there? Well, for one, I didn’t have the option to create a rock opera about Dracula (I kid). But as stated above, I truly believed that the company would grow and along with that would come personal opportunities. The key benefits to working for this company were:

  • Growth Potential
  • I was given tremendous amounts of responsibility early, which was frequently a rewarding challenge
  • I viewed the job as a resume builder, thinking that I could land any job after about 3 years
  • My colleagues were great to work with and are some of my best friends today
  • I got to work on brand new Microsoft technologies

“It’s really good, Peter. I just don’t understand it”

3 posts now have revolved around my time working at this company. It’s time to get to the point by explaining what I learned by constantly having to “walk on egg shells.”

  • It pushed my leadership ability to a new level. I was forced into making technical leadership decisions within a short period of time after beginning the job. Because of the high turnover, I went from being the 3rd most experienced technical person in the company to the 1st. This meant that I had to learn to make decisions without the reliance of someone who had relevant experience.
  • I learned when and how to speak up, to voice my opinion.
  • I learned that it is important to be able to articulate the points for or against a decision.
    • When responding negatively to news about a decision, I learned to be able to describe reasons why a decision made me uncomfortable.
    • When presenting, it is important to start with an “Executive Overview”; don’t assume that the audience knows immediately what you’re talking about.
    • When selling an idea, I learned to prepare for critique and to validate benefits.

Perhaps most importantly, I began to understand how stressful it can be to own/bootstrap your own company. For the owner, his or her entire livelihood is at stake every day. The occasional emotional response to bad news can be expected.


Hire ‘em and Ignore ‘em – Another Anti-Pattern

This blog post is the 2nd in a series of Anti-Pattern stories

As I wrote in my last post, turnover at one of my previous employers was abysmal, a dreadful 50% each year. I don’t know the industry calculation for employee turnover but here’s mine:

Count the number of people at the company on January 1.

If half those people are not there a year later, then that’s 50% turnover.

I also mentioned in the last post that the company was fairly small. I think it’s fair to say the company’s growth was restricted by the continual loss of (mostly) talented employees. Nevertheless, you would think that a company with so much experience filling vacant roles would have become effective at training and onboarding new hires.

On the contrary, this company’s orientation process was inconsistent at best, nonexistent at worst. Instead of a new employee’s excitement being maximized during its peak, it was met with a complete lack of direction. Whatever willingness to learn and sacrifice the employee had was quickly drained with feelings of boredom, irrelevance, and defeat. The culture had become so rotten that some company members actively avoided new hires until they had “established they could cut it.” In other words, it was not considered worth the time to introduce one’s self to a new employee until he or she survived a certain minimum number of weeks on the job. Another common scenario was that new employees were not given any tasks or attention when they started. They were just left at their cubicles to stare at their computer monitors and look busy. They usually did not know who to ask for help or for more work to do so they became frustrated with the lack of mental challenge and began wondering what alternative employment options existed.

Exciting Lunch

Posted by jmerriam7

As I alluded in my previous post, a more dramatic scenario occurred when new hires were introduced to their first “dropped bomb,” when an ambiguous “corporate catastrophe” was explained in a monthly meeting. They were incidentally led to believe their jobs were in jeopardy, leading them to revert to their recent yet unsatisfied job search as a fallback option.

It is my belief that new employees require attentive treatment and care in order to rapidly train them how to do their jobs and more importantly to reduce turnover. In many cases, companies are willing to spend time and money on recruiting talented employees, but next to zero time on them once they have signed an employment agreement. With a thorough employee orientation program, new hires are incorporated into existing teams and they feel confident about their efforts, abilities, and the organization. They begin to produce results earlier begetting momentum and a sense of accomplishment. Doesn’t this sound like a better outcome?

Accordingly, if you remember only one thing from this post, remember this:

Employees in orientation must still be recruited!

 

Below I outline a few recommendations for new hire orientation. They may seem like remedial suggestions but I can assure you they are new concepts to at least one company. Picking and choosing even a few to implement should increase morale and productivity of new employees.

Introduce the new hire to people with whom he or she will interact regularly

One of the goals of employee orientation is rapid integration into the existing team. Introduce a new hire to close (in proximity or function) employees on the first or second day. If the company is small enough, introduce him or her to everyone in the organization.

Take the new hire out to lunch with the team

Ideally this would take place on the first day. When the new hire is eating lunch with peers, he or she can begin to ask less formal questions about the job or company history.

“Pair up” the new hire with someone knowledgeable

Ideally, there will be an experienced member of the new hire’s team in a similar role. The experienced member should teach techniques and best practices to the new hire. Additionally, this semi-formal pairing provides comfort to the new hire that there is always someone that can answer questions.

Formally train the new hire

For smaller organizations this is not as practical, as most knowledge is tribal. However, medium-to-larger organizations with established roles often spend the first few days or weeks training new hires in a classroom. Such focused learning of company-specific knowledge reduces experience needed to perform the job.

Implement a formal mentor/mentee arrangement between different departments

Pair a new hire up with an experienced company member from a separate department. The experienced member should be given knowledge of what is expected of a mentor in such a capacity. The mentor schedules regular (e.g. weekly or monthly) meetings with the mentee. This setup provides new hires the opportunity to ask questions about corporate culture or specific difficult scenarios without concerns of corporate politics.

Develop a central knowledge base

This often takes place in the form of a wiki. New hires should be directed to an internal web application that can be searched for information that has helped employees in the past.

Setup a new hire’s computer and working environment

.NET developers like me encounter this anti-pattern frequently. We show up on our first day and are given a laptop with a fresh installation of Windows on it and administrator privileges. We are expected to spend the day (or however long it takes) installing the software needed to perform our jobs. Visual Studio alone takes about half a day to install, so you can imagine the extremely unproductive time wasted on staring at progress bars. I recommend setting up the computer to a point past all the down time. It should be easy for a current developer to work on his or her own computer while another one is plugged in at its side getting important programs installed. If there are specific development environment configuration settings that a new developer should know, leave those incomplete for a learning experience.

 

Retaining newly-hired employees is essential for organizational progress. Great opportunities are lost when employees leave your company before significantly contributing to its success. The company loses money and time on recruitment, training, salary, and also could lose the opportunity to hire the second-best candidate, who likely has joined another company already. By implementing an orientation program with some of the above strategies, turnover of new hires can be greatly reduced. And if a company-wide “restructuring” must occur, at least show some sensitivity to the employees that are considered valuable so that they feel secure in their positions.

 

 

 

2 Steps Forward, 3 Steps Back – A Leader’s Anti-Pattern

Recently, I have struggled to maintain the blogging pace (1 every 4 weeks) that I set as a goal for myself at the beginning of the year. The difficulty can be easily explained. I have been meaning to share some stories from past experiences. However, I have hesitated, worrying that by publicly displaying my thoughts about sensitive topics I could be burning the bridges I have built with past colleagues. Ultimately, I’ve decided to write about some lessons learned based on advice from a mentor, “sharing how you overcame difficult situations is always a good thing.” I will attempt to be objective in my recollection as opposed to writing a long-winded rant. Names will be withheld to protect the guilty. Nevertheless, I can say with certainty that the chaotic, passive-aggressive environment of the following situations taught me more about dealing with superiors and office culture than anything else.

Since I plan on writing more than one post around the same topic, it is useful to spend a little effort describing the culture at my previous employer. First of all, the company was small. It was big enough and established enough to not be considered a startup anymore. However, it was small enough that any change that ownership decided on could be carried out in a matter of days, and drastic decisions were made… frequently.

Once a month, all employees met over a long lunch to discuss important topics, like current status, growth, and direction of the company. This was not an abnormal concept, but it was at these meetings where we were met, more often than not, with such flummoxing news that we all left in disbelief. We began to walk into the meetings each month expecting a new “bomb to be dropped” on us employees. Despite hearing that company financials were good, we would learn of a completely new corporate direction. Also typical would be revocations of previously approved “perks.” Or, as we looked to our left and right and noticed certain people were not in attendance, we would soon find out that these folks had been fired unexpectedly that day.

At the time, I merely chalked everything up to the passive-aggressive nature of leadership. But now, looking back, I realize what was happening was a lack of trust, and therefore a constant evasion of policies, conversations, and tactics that had previously caused pain. The moment anything went wrong, then in the eyes of those making decisions, it meant that everything on which the company was focusing was wrong, and changes needed to be made in the opposite direction. Put another way, the strategies being implemented may have been near perfect, but they were immediately abandoned at the first setback. It is this anti-pattern on which I will elaborate today, but first, I want to share an excerpt from a journal I wrote while on the job:

No one really ever knows if they’re doing a good job. “Reviews” have been neglected over the last 8 months. And, although we have a “Vision” statement, our environment changes so often and our direction always comes from one source, that it makes everyone feel like whatever they were working on before wasn’t right.

Another source for this is that we have high turnover here. So, if someone learns some method or process from someone else who was terminated, the thing learned gets questioned even though it might be highly valuable.

I think a way to resolve this is to understand that it occurs. When there is turnover, either more could be explained, or there should be a more thorough strategy for picking up the focus that the resource had.

 

The Solicitation of Advice

Recognizing that turnover was high and morale and productivity were low, leadership asked me and another employee to lead 2 workgroups over the course of several weeks to brainstorm areas at which the company needed to improve. The idea was that recommendation documents from each workgroup could be created somewhat anonymously, and would result in an honest, public discussion with the owner. The documents would follow a What, Why, and What’s Next format for each suggestion.

I cannot speak for the other workgroup, but mine was thoroughly engaged in the process of trying to “fix” the issues of the company. We spent hours brainstorming, collaborating, and refining our recommendations, but we ultimately knew that no policy change or employee benefit would take root unless a culture of trust arose first. Our message was clear. We aspired to a culture of trust in which we communicated openly, trusted the intentions of colleagues, and were patient with decisions based on education and experience. In order to fit the requirements of the document, we provided specific examples of ideas for change in addition to an overview wherein our culture of trust concept was explained (if you knew our audience, you would know how important adhering to the proposed document structure really was).

Eventually, our deadline arrived along with the promised “open” discussion. The owner was the solicitor of our recommendations and the authority for taking action. Our workgroup’s mission was to pitch our ideas on paper and await the resulting changes. Going into the meeting, I was excited about making a truthful, heartfelt, objective, and passionate case for change. My hopes were quickly squashed.

The owner had a day to review recommendations before the meeting. However, it apparently was not long enough to enable an objective reaction. The meeting kicked off with defensive remarks rebutting the specifics of nearly every recommendation. Those of us who were more vocal, or who had less to lose, prudently responded calmly, arguing for the case of the documents.

As you may have guessed, the multi-hour clash was all for naught. The owner, citing past misbehaviors by employees (most of whom were no longer employed there), told us we “were not mature enough to handle these changes.” The entire discussion focused on arguing specific points about low priority recommendations and how they would be carried out. It became emotional. The overarching message was not heard, nor internalized.

Maybe it was better to receive an immediate negative response than to follow the company’s normal trend of putting changes into place only to lose faith in those changes soon after. Still, that was the 2nd “bomb” I endured at the company, and it illustrates one of the biggest anti-patterns that was so common. We were given hope in the form of solicited advice, but absolutely zero progress resulted. The owner had effectively reduced morale to nil. There was a fleeting moment of trust (2 steps forward) followed by the regression to a comfortable status quo, except the engagement of several of us was lost in the process (the 3 steps back).