I started working with software developers a little under ten years ago. Coming from a business background, my predominant work was communication and relating. But I began to work with people who would spend more time creating, designing, and building products. I had to relearn my 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 the 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 of 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), a book by Gino Wickman and Mark C. Winters, introduces the concepts of Visionary and Integrators.
I’ll detail the concepts in this post and explain how they helped me build connections with the most introverted members of my teams and improved my coaching them tremendously.
Manager vs Maker
Paul Graham explains why developers dislike meetings: meetings are huge interrupters in their work. He describes the reasoning by creating two concepts: the manager’s and maker’s schedules.
Most people function based on a manager’s schedule: you check someone’s calendar, book a meeting where you find a free slot, and are done with it. Also, your calendar is filled with meetings, some 30 minutes apart, some hours apart, but nevertheless, there is no actual structure in how you receive meeting invitations. And for a non-creative, this way of working functions well and is not disruptive.
A maker’s schedule has an entirely different approach altogether. Makers need many blocks of time booked to do their creative work. As a result, a meeting can disrupt their entire day and tremendously affect the developer’s productivity.
When you are focused on solving a problem or creating a new solution or design, you dive deeper into the issue as you work. An interruption can catch you at your peak point. Detaching from the problem you were working on, completely switching contexts and focusing on a different meeting is very costly in terms of time and energy. Returning to your work is not as easy as “let’s see, where was I” and continuing like nothing happened. It takes time to reach the peak of your insight again and get back in the 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. Some developers can be interrupted without issues, and others need long periods 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.
- I book most of my meetings on certain days and keep long batches of time (minimum 2 hours) for creative work. I reserve those blocks of time in my calendar, so they are not stolen from me.
Makers vs Menders
Not all developers want to create the next best application or the next new shiny thing. Instead, some developers love to work on existing systems and find satisfaction in improving them.
Andrea Goulet calls the developers excited about building MVPs and creating new application 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. Contrastingly, menders like to work on 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 they can do best and motivates them.
What can you do to help the team?
- First of all, share this article with your team and discuss it. Where do your developers stand? Who are the makers? Who are the menders?
- When that is established, have them discuss 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 getting the best results and helping a team reach high performance.
Visionary vs Integrator
My last example doesn’t directly connect with improving your work with developers. Instead, Rocket Fuel presents two types of leaders in small businesses: the Visionary and the Integrator. One sees the future, and the other makes it happen. These two roles working together create magic, according to the authors. Think of Steve Jobs and Steve Wozniak, for example.
The Visionary
The Visionary is passionate about their product, customer, idea, continuous learner, entrepreneurial, creator and most likely the company’s founder. They work well with uncertainty, see trends and strategic directions for the product, and adapt quickly to changes.
The Integrator
The Integrators are called Number Two, the COO or the 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 an Integrator. I love to make things happen, see the intricacies of the organisation’s systems, processes and human relations and model them to work at their best.
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 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. For example, are they Integrators of Visionaries? Where do they see themselves, and 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.
Agents of Awareness 
Leave a Reply