A little under ten years ago I started to work with software developers. Coming from a business background, my predominant work was related to communication and relating. But I started to work with people who would spend more time in creating, designing, and building products. I had to relearn my entire approach to work, communication, meeting settings and generally my working style.
Learning meant talking with the developers, designers, or other creatives I worked with about their working styles, and how they are most productive during a day. I also started to learn how to code (I got to the level where I can edit websites and I did so in my work repeatedly, and currently I’m back to learning Python) to understand how a developer’s thinking process goes and how to approach solving complex problems.
On the way I found great resources that helped me improve my working with developers. I am sharing here three concepts that were recommended by several members in my team, as long as five years ago:
- Paul Graham’s post on makers managers (2009)
- Andrea Goulet’s post on makers versus menders (2016)
- Rocket Fuel: The One Essential Combination That Will Get You More of What You Want from Your Business (2016), book written by Gino Wickman and Mark C. Winters, that introduces the concepts of Visionary and Integrators.
I’ll detail the concepts in this post and explain how they help me build connections with the most introverted members of my teams and improved my coaching them tremendously.
Paul Graham has the best explanation why developers dislike meetings: meetings are huge interrupters in their working. He explains the reasoning by creating two separate concepts: manager’s schedule and maker’s schedule
Most of us function based on a manager’s schedule: we check someone’s calendar, we book a meeting where we find a free slot and we’re done with it. Also our calendar is filled with meetings, some 30 minutes apart, some hours apart, but nevertheless there is no real structure in how we receive meeting invitation. And for a non-creative, this way of working functions well and is not disruptive in any way.
A maker’s schedule has an entirely different approach altogether. Makers need big chunk of times blocked where they can do their creative work. A meeting can be as disruptive as to disrupt their entire day, and tremendously affect the developer’s productivity.
My developers explained to me why: when you are focused on solving a problem, or creating a new solution or design, you dive deeper into the problem as you work. An interruption can catch you into your peak point. Detaching from the problem you were working on, completely switching context and focusing on a different meeting, will be very costly in terms of time and energy. Returning back to your work is not as easy as “let’s see, where was I” and continue like nothing happened. It takes quite an amount of time to reach the peak of your insight again and get back in flow.
What can you do to help the team?
Share Graham’s article with the team and have a conversation about it. Have your team share with each other their working habits and styles. There are developers that can be interrupted without any issue, and others that need long period of times for them to create their best work.
As much as possible, set meetings around periods when the developers take breaks naturally; my favourite is after lunch, or immediately after the daily huddle.
Not all developers want to create the next best app, or the next new shiny thing. There are developers that love to work on existing systems and find satisfaction from improving them.
Andrea Goulet calls the developers that are excited about building MVPs and creating new apps makers, while the ones that prefer to work on existing systems and make them grow are menders.
Makers find satisfaction in working with a blank canvas, testing a new idea and giving birth to new products, while menders like to work on the fine details and craftsmanship, considering things like refactoring, security, performance, scalability, etc.
The differentiation is of great help if you want your developers to work on the things that they can do best and bring them the highest motivation.
What can you do to help the team?
First of all, share this article with your team and have a conversation about it. Where do your developers stand? Who are the makers, who are the menders?
When that is established, have them discuss with each other what motivates them more; if they understand what the person next to them loves doing, their collaboration will be much more effective.
Next, ask them if they’re working on the right things. Are the makers testing new ideas, and are the menders stabilising existing systems? Try to organise work around their preferences: allow makers to experiment (within a deadline), and give menders small wins during the day. It’s one more step to get the best results and help a team reach high performance.
My last example doesn’t have a direct connection with improving your work with developers. Rocket Fuel presents two types of leaders in small businesses: the “Visionary” and the “Integrator“. One sees the future, the other makes it happen. These two roles working together creates magic, according to the authors :). Think Steve Job and Steve Wozniak for a better picture.
The Visionary is passionate about their product, customer, idea, continuous learner, entrepreneurial, creator and most likely the founder of a company. They work really well with uncertainty, see trends and strategic directions for the product, and can adapt fast to changes.
The Integrators are referred to as number 2, COO, inside man, and their role and skills are unique: they make someone else’s vision happen. They are “a person who has the Unique Ability® to harmoniously integrate the major functions of the business, run the organisation, and manage the day-to-day issues that arise”.
What can you do to help the team?
The first thing that was evident to me while reading the book was that I am clearly an Integrator. I love to make things happen, to see the intricacies of the systems, processes and human relations in the Organisation and model them to work at their best.
I think each of us has a visionary or integrator approach to our work: just like makers and menders above, there will be developers that love to envision, build strategies for the product, and think of what needs to be done next, what’s the industry trend and what else can be done to make the product great; at the same time, there are developers that get excited about the “how” to make things happen – what system to use, how to scale, performance, quality and so on.
Present the concepts to the teams, and have a conversation about them. Are they Integrators of Visionaries? Where do they see themselves, why do they see themselves in that position? Does the work they’re currently doing fit their objectives and working style?
I consider this to be another method to help the team get to know each other and understand how to better distribute work and use each other’s strengths to reach high performance.