Once a quarter, my company puts on an internal conference for continued education. It covers a wide breadth of topics, from quality assurance to mobile development to security. I am responsible for the cloud sessions.
Every few months I reach out to some people at the company who are into cloud development and ask them if they'd like to present a session to other developers who are looking to get into the cloud. This quarter was no exception.
We have three sessions coming up that extend a bit beyond the basics: NoSQL data modelling and single table design, building an image processing service with S3, and how to design a serverless event-driven application. Pretty exciting stuff if you ask me.
I was doing the administrative work around getting these sessions added to the conference when it hit me. These three sessions could build on each other to make a high quality application. A cohesive set of related sessions will not only keep engagement longer, but will also help drive the ideas each one is presenting by demonstrating how the pieces fit into the puzzle.
So I spoke with the presenters and we came up with the idea to create a photo sharing application. The app allows users to upload photos which automatically get tagged by an ML image recognition service, then it notifies people who have subscribed to certain tags. Check, check, and check!
Our conference app intro slide
We recruited one other engineer who is a rockstar front end developer and got to work. We built the app over the course of a few hours in a couple days since we still had our days jobs to do. The amount of progress we made in such little time was astonishing and made me think back to when I was a development manager and why our day-to-day isn't always this fast and fun.
It's About People, Not Process
In our conference project, each one of the four of us took the work we knew inside and out. We played to our skills. A luxury we don't always get when following the home-grown processes of a normal development team.
Instead of writing a bunch of stories and everyone pull from the top of the list, we divided up the work, setup a dedicated slack channel, and wrote some code. When there was a question or a roadblock, we posted it in slack and got our answer in seconds.
When we focus on following a process, we lose some of that agility - even if the process is designed to increase agility. Allen Holub reminds us what Agile development is at its core:
Our goal was exactly that. To do the minimum, keep each other unblocked, and make it easier to move forward.
That is the power of a high-functioning team.
Awareness. Desire to help. Feeling a sense of team. Driving toward a common goal.
Our little group of engineers don't normally work together. We're all friends and communicate regularly, but on a day to day basis we're on separate teams. Yet we came together and did a month's worth of work in just a couple days.
Don't get me wrong, processes are important. They help streamline work, they give you an idea if you're ahead or behind your timeline, and they provide a general sense of consistency. But they need to be maintained.
It's like driving a car.
You drive your car every day. It works great and gets you where you need to go. But every 6 months you need to get an oil change. And every couple of years you need to get a tune up. Without it, your car will begin to perform worse and worse until eventually it just stops working.
Processes are like this. If you don't work at keeping them optimized they will eventually get in the way of development and ultimately stop being effective.
Build your people. They will recognize when things start to go south.
Building Your Team
My little impromptu team is a unicorn. It was composed of me and three of the best engineers I have ever worked with. Talk about making yourself the dumbest person in the room!
Realistically we can't all build teams of the best engineers we know. So how do we go from where we are now to becoming a high functioning powerhouse?
Instill a sense of ownership and pride in what your team does. Help them feel like they work with their friends and that they can influence real change.
It's not smoke and mirrors, as the leader of a team you can make this happen! Empower your team members to make suggestions and take ownership of something. Build an expertise in a problem area and teach others the nuance they learned.
Remember, it's about the people, not the process.
A high functioning team will be self-managing. The people know what they are best at and know who to ask when they need help. They communicate with each other. The more in sync the members of your team are with one another, the more high functioning you become.
Let your team foster their relationships, then build the processes around what works.
Final Thoughts
Never underestimate the power of a high functioning team. They can pull together, bounce ideas off each other, and get a crazy amount of work done in a short amount of time.
It is all founded on relationship building. A bunch of strangers won't be able to bob and weave together without practice. They also won't go to each other and ask for help as much as they should.
Processes are put in place to help foster work. If left unchecked, they quickly turn into obstructive governance for the sake of process. Use processes as a tool to help your team communicate.
Don't know how to start? Try engaging your team in a hackathon. The short, competitive nature of a hackathon will quickly bring out self-coordination among the members of your team so you can see who naturally leans toward specific components when building something new.
Take your lessons learned, run a retrospective, and begin nurturing the strengths of the members of your team. Encourage constant communication and your team's productivity and overall happiness will skyrocket.
Best of luck and happy coding!
Top comments (0)