Fellow UM consultant Andrew Powell talked about the RIA Team Concept. That inspired me to write about my recent team building experience.
I had the opportunity 3 months ago to augment my team. Placed on a large Flash development project, I knew I couldn’t do it alone with the resources I had. That’s what my gut said. It took me about 3 business days to identify the scope of the project based on what I was told from various stakeholders (dude’s and dude’tt’s in charge). It took another 5 business days to identity the true extent of what available resources I had. I’ve had no formal training in resource management. A resource being defined as a person with a skill set that is valuable to my team. Typically, I’ve been an added resource to a team, a Flash / Flex Developer hired to enhance an existing team. This time around, I was looked upon as the person who could correctly identify who, and how many, additional people we needed.
I looked at the project’s scope & deadline, people I currently had available, and knew I needed help. How?
- I’ve done enough development before to know what I’m capable of.
- Over time, I can recognize people’s skill sets, and make an inference as to what they can accomplish in a given time frame.
- I’ve done enough variety of work to recognize what skill set does what type of work best.
Those 3 are mostly drawn from experience. Experience can’t be taught, it must be lived. Regardless, reporting on experience helps others learn how they came to be, and as we understand others’ experiences, we can understand ourselves.
There were some obvious signs of what we DIDN’T need. The project was a refresh; meaning, an existing website was adding a new design and changing some functionality. The data, all dynamic from a set of .NET web services on the back-end, was not changing. If it was, there were numerous in house resources that management assured me would be more than capable of knocking them out quickly while being flexible to requirements.
Good, no need for server dudes. Bad thing, though, these gals n’ guys are easier to find than client peeps, say… a qualified Flash Developer.
The single developer I was assigned to work with was not a designer. I am not a designer, I just like designers. I knew we needed a designer. Even if it wasn’t the one actually designing the new site, we needed someone to be accountable for the design in my team. Developers tend to have no regard for layout, font choice / size / weight, and will ignore gradients that don’t display on their monitor. It’s not that we can’t, it’s just we aren’t paid to do those things; we’re typically focused on making things work, not look good. As such, we needed someone to work with us to keep us in check. Having a design change break working code that was fought hard for 2 months later is a major morale & productivity killer. As such, you need to massage it into submission while the patient is open. A designer working with the programmers to ensure the design is correct and to help adjust to design requirement changes should be done in tandem, not at the end of a project.
I needed a designer.
Another week into it, I realized we weren’t allowed to rewrite things. I wanted to nuke the whole code base, but that wasn’t in the time frame. That’s always a joke in the Flash industry because you can typically re-write bad ActionScript faster and end up with something with less bugs, easier to test, and more scalable anyway in the end if you know what you are doing. The trick is how do you sell that to management? Do you do it anyway, risking that if you take longer you defied orders, or instead look like a hero at the end? All kinds of crazy, ethical blurriness here. That, combined with the insane deadline + the amount of code to jury-rig into submission was… daunting. Considering I had a seasoned programmer on my side, I felt good. He didn’t have any Flashdev experience, however, so I knew I’d do a lot of peer programming. Peer programming being defined as 2 programmers using 1 computer to program. I do this a lot for solving bugs with my teammates . He’d teach me about the code base since he had experience with it as well as the business. In turn, I’d explain why you can’t mask device text at author time in the Flash Player, why the existing code base was f00ked via copious justifications, and all of those other nuances us Flash Developers know about our platform. That means 2 developers barely making headway. I needed someone else doing recon in other areas, covering our backs, and generally being a work horse while us two forged ahead in deadly waters.
I needed an additional, experienced Flash or Flex developer… preferably Flash.
Another week into it, the sheer amount of “screens” and “sections” made me realize that there would be a lot of production art. Production art being the process of converting Photoshop, Illustrator, or Flash FLA files into a design that can be programmed inside of the authoring tool, in this case the Flash 8 IDE. This is, unfortunately, an art. Designers can be pretty good at this, but it is rare that programmers are because a lot do not have a design appreciation for the assets they are converting, and thus quality and intent can be lost in the conversion process. As the tools in the industry get better and more integrated, hopefully this skill set will go away (*ahem* :: cough :: :: Adobe :: :: cough :: ), but for now it is a necessary evil. It has a worse perception than Information Architecture in that many do not even recognize it as a skill, let alone a valid task. This one requires a lot of educating management very delicately if it’s considered new.
I needed yet another designer. They could not only use Flash from a designer’s perspective, convert assets, but also ensure us programmers aren’t making a mess of the implemented designs.
So, I managed to get:
- 1 in-house programmer, experienced with the code base and business
- 1 in-house designer, experienced with the business
- 1 remote developer brought on site with Flash Developer experience
- 1 remote designer brought on site with Flash Design / Development experience
The whole time, I managed to convince management to allow us to all work in the same office. That’s right, 5 dudes in the same office. Because of the deadline, remote work wasn’t possible as far as I was concerned… at least at the get-go. The in-house designer was originally on a different floor, but f’that . After 2 days of IM’s, phone calls, and trips to the elevator, my team and I had had it. We apprehended some fans, and even snagged an extra whiteboard. I did my best to make Twizzlers always available. Unexpectedly (to me), management started ensuring that our productive garden thrived, and watered us with facts gleaned from copious meetings we didn’t have to attend, and gave us sun beams of praise. It was great how it worked out!
I feel I made good decisions, and things worked out better than I thought they would. I was really nervous at the beginning asking for so many resources, both internal at the client company I was consulting for, and from my own consulting firm. I’m technically asking both companies for a lot of time and money from various individuals. Those are not decisions to be taken lightly. I’ve never argued with my gut, though. If he says jump, I jump. All the experience collects there, you see. Thus, I trust it implicitly. Yes, yes, I swear I did some double-takes and did some second-guesses just in case. Nothing like role-playing devils’ advocate, out loud, near others who you shouldn’t be role-playing near.
The only challenges were keeping the designers focused 100% of the time. Forces outside of our control made it challenging to present them production work in a steady stream. Additionally, the amount of bugs and code re-factoring made it hard for us developers to showcase completed sections for the designers to do their thing on. I am constantly playing catch up to find valid sections that are ready for “painting” or “design inspection” as it were. QA became a good scapegoat (aka back up task) but RAD development, even with a good plan, isn’t always everyone going 100%. Developers, even in agency work, are always slower than designers.
Anyway, I know the above was kind of vague, but hopefully that give you some insight into how I made my decisions. I made the mistake in the past of not asking for additional resources sooner, so learned from that, and nipped the problem before we hit the starting gate. I am glad I was given this opportunity to learn and am glad it worked out so well. I typically write about the hard lessons I’ve learned from failures, but this is a success so it’s a nice change.
If possible, could you share some experiences you had making this team a TEAM? From my experience it takes a certain time for a team to be productive and that is usually not a technical thing but a social issue. You need to get ti know eachother, know eachothers strengths and weakness and most important, eachother personalities. The best (technical) project manager for the team members pov is the one that has the rare ability to grow a team using his experience to build a rock-solid team that can handle any killing deadline.
I agree about learning your co-workers, and getting a feel for each other. As a consultant, I’m learning how to get integrated and up-and-running quickly. I changed schools a lot as a kid, and thus had to learn to adapt to new social situations quickly to fit in. I think that is serving me now to quickly learn who someone is and how to approach them. You can then use those same people skills to see how they interact in social situations, and recognize the good interactions and bad ones, and do your best to facilitate the positive ones.
People have buttons too. You know which ones to press, when, and which ones not too. If someone is good at quickly knowing some one, they can also be a mediator. I feel I’ve been good at keeping the peace since I f’ing hate conflict and loathe drama. It’s best to get the crap out the door, and quickly.
Obviously, it’s best if someone is assigned this role, like a manager / team leader / architect, etc. Accountability for your leadership role is important. Sometimes these things are defined, and other times you just play by ear.
To give more concrete examples, I learned I couldn’t sell my developer team member on Flash best programming practices. He was too much like me, and could see through bullshit. So, together we did things horrible, and then did things right. This allowed him to gain the appreciation I had, in the exact same way I had. While it took longer, it was the most effective; I would know since we are a lot a like.
The designer constantly had feelings he wanted to express. I could tell by his body language and response to statements about what to do next. Consistently, his knowledge of the business helped define better plans of attack for the entire team. So, instead of stating things, I’d ask rhetorically, and be sincere in asking for feedback.
One developer consistently questioned our development strategy. At first I didn’t feel like explaining, but realized that was extremely unfair since we were all equal. I actually ended up liking it because it reminded me of myself questioning everything. So, using a viable task, I set him upon tackling a more challenging aspect of the project. Upon integration, he started recognizing a lot of the reasons I took the approaches I did. I also learned that his questions always had an ulterior motive and as long as I worked to facilitate his research rather than take over it, we had good synergy.
The other designer I learned was most productive and happy when given clear directions. For someone so easy going, you’d think it’d be easy to please him. It wasn’t mainly because I had so much whack stuff on my plate, and it was hard to give clear direction when I barely knew it myself. As long as I was honest, he was cool with that rather than being fed a line of bs and getting irritated further.
I found the team was productive when left to their own devices; when outside forces inserted doubt or uncertainty, productivity went down. I did my best to spearhead any unsure initiatives, or quash any outstanding unknowns. Management was very helpful & supportive in this endeavor.
Going out to lunch, frequently, helps better to get know your team. You don’t have to talk to them, just listen; watch their interactions. When something frustrations them, don’t get frustrated too; try to understand why they are frustrated. You can act to avoid those frustrations in the future.
The direct approach is great to. What do you like? Why are you here? What are you doing this for? This line of work; what is the point? Those kinds of hard line questions give you a better sense of the person, but can be perceived as being very personal. Alcohol helps remove inhibitions to answering those questions.
Finally, making sure everyone was in their niche. If you are doing something you are good at and like, you can get in the zone. A group of devs in the zone is a neat thing to see and good work, good teamwork, comes from it.
jesse-great insight on team building during a project. THe stuff about ‘production art’ not being understood as a legitimate line item hits home. Many times i get source art in PPT/word files and the customer can’t understand why there is money billed for conversion or cleanup of the art. I’ve actually taken my lapto over and walked thrrough the process with a customer watching to show it and then have them mutiply by 250 pieces planned for in the course. Then they get it. But it is a battle. How do you deal with team members who want to ‘do it all’ on these projects-designer/developer hybrids?
If they want to do it all, and it’s possible for them to do so, let them. Nothing wrong with a rockstar as long as they are producing quality work and aren’t burning themselves out.
If they are not busy enough, that’s management’s fault.
If they ‘feel’ like they can do everything, they need to learn to be a team player and work with others. There is nothing wrong with being good at a lot of things. In a team environment, however, more people produce exponentially more work and/or better quality work if it is run correctly. As such, they need to be a part of that.
If leadership isn’t put in place to be held accountable for this person’s actions, this is both the fault of management for not having the proper leadership setup, and for not setting proper expectations of the employee.
I’ve found most things in IT are all managements fault. I’ve f’ed up royally a few times, but I agree with the statistic thrown around online that 95% of all IT projects that fail are not a result of any IT or technological failing, but rather management.
The designer hybrid we had on our project was great. He knew the business, knew the tools, and could help out a lot. Therefore, I threw a ton of work his way. If he’s busy working, he isn’t asking to do our work.