The year was 2000 (that still sounds odd to say, like it’s a scene out of a science fiction movie) and I signed up to complete a post-graduate degree in information technology. It was a 3.5 year program packed into just under 1 year. I needed a change from the health care field and seeing the growth in technology at the time, I believed this was my next logical path.
The school kicked off like any other. The class was about 50 people in total. The diversity of the class in terms of culture and professional backgrounds also varied greatly. I was excited about this because I knew I’d have a chance to learn from people beyond just learning to code.
The morning classes were a group session with an instructor teaching the basics in a particular coding language. We’d break for lunch and then in the afternoons we were put into teams. Each team was given a case study / use cases. This was what we would have to build as a team by the end of the session.
There were no time limits as to how long we needed to stay after that morning class. You could stay for an hour and then leave or you could spend the night. The only thing we knew was by the time that specific session was done we had to present a working prototype to the class as if we were presenting to the client.
Teams were selected based on some loose criteria at first – basic backgrounds, whether you had coding experience or not, etc. I can still recall the first session and one team that jelled instantly. They were acting like long lost friends that were reunited after a decade.
My team was quiet and respectable with one individual who had a strong background in code. We never ran into many conflicts as a team. At the end of the first session we presented with success. The application worked, checking all the boxes for the client, in addition to a couple of extras. Everyone passed our individual exams along the way – and we were off to our next coding language.
I looked at my new team and didn’t think anything of it. I went around the room and introduced myself and we got together to learn about Visual Basic. It wasn’t until about the second week when I realized how teams were decided upon. Tension and arguments started to become more frequent across all teams. Some even stormed out of the building. While my team had fundamental differences of opinion, I don’t recall any detrimental arguments.
At this point we had all gotten to know each other better. We’d go out for drinks after class and joke about different experiences. One individual had this uncanny ability to code perpetual loops – unintentionally – in every language. We’d play Unreal tournament and I would constantly get blown out of the sky. Everyone laughed “Sparky got blown up” I’d come back to life and thirty seconds later, “Sparky got destroyed” again. Everyone would laugh, I’d sarcastically curse and laugh along with everyone else.
One day in the second session I approached two of the instructors with great interest in how teams were formed. “Hey Dave and Tina. Do you have a minute?” They stopped what they were doing, swung around in their chairs. “You bet! What’s up Jeff?” I sat down and pondered how to ask this question.
“I’m curious about how this school picks teams? Clearly you aren’t picking teams for efficiency in getting the projects completed for the made up client. We’re in Java now and I’m struggling to understand how I fit into my team. I mean, everyone on my team has a background in code. I’m struggling to learn the language and I’m also having to pull the team together. Everyone is taking off in their own direction and…” I paused. I must have looked like “ohhhhh I get it now” because without saying anything else Dave and Tina just smiled at me.
I’ll never forget this discussion because it has remained true through every industry and sector I’ve lead in the last two decades. Tina began with a statement of reassurance “We’ll help you get through Java. Keep in mind this course is not setting anyone up to be a master programmer. Anyone learning code will have to focus in that area. It will take years of trial and error to be that good; it’s not unlike becoming an expert in any field.”
Dave politely interjected, “To answer your question, we create teams that we know will create conflict based on individual strengths and weaknesses. We do this because in the real world you don’t get to pick your team; but you still have to deliver. You’re not the strongest programmer. Your strength is in aligning people and resolving conflict to get things done.”
There are points in your life and career that stand out. I’m not sure why that specific conversation has stayed with me. Perhaps it was reassurance that my work in psychology was going to help me move forward in tech? Maybe I just found solace in the idea that there was a plan behind being put on teams that didn’t feel connected.
Field Notes
Over the years, the tools we use to design have evolved in their complexity towards simplicity. Where complex tools like Photoshop and Illustrator were the only professional standards, today Figma, Sketch, Abstract, InVision, Framer and many more have come to be the standard.
It is that space in time in between Photoshop and Sketch where it was a normal part of the learning experience to understand code and the tools to design, simultaneously. Because of the speed at which these tools evolved, learning to code is no longer an essential skill for most designers. Over the last several years there has became a propensity for the design world to insist that designers know how to code.
If you don’t understand the platform even at a basic level, for example, then regardless of your title, you can’t understand what can be done simply and that which cannot. It’s not about being able to sit in the developer’s chair and do their job; it’s about respecting the complexity of the platform and being able to design accordingly.
While many designers I’ve worked with – who are outstanding at their job – see these as barriers to creativity, I’ve always tried to demonstrate the opportunity to build stronger ties with developers and learn about the objectives of the business.
Conflicting ideas and opinions are a part of any team. The successful individuals are always those who recognize what they don’t know and are willing to learn from others. What have you done to learn more from those you work with directly and indirectly? Have you tried to learn the platform? Have you tried to understand why IA is fundamental to AI?