It is my immense pleasure to present an interesting conversation with Doc Norton during the interview. He has been really enthusiastic and participative in the entire process that resulted in a valuable set of information for our readers. Here you go;
Q.1 What introduction would you like to be given to the uninitiated?
Doc: I am a problem solver at heart. As a kid, it was the Rubik’s Cube (long before the internet) or wooden puzzles my dad used to collect. As an adult, software development scratched that itch. After a lot of bad experiences, and a few good, I started to see that most problems with software were not the team, but the environment. Since then, I’ve focused as much as possible on helping companies think holistically about software and product development by looking at organizational structures, management styles, and decision making protocols that are more conducive to effective software delivery.
Q2. How important is collaborative decision making in software development?
Doc: Oooo, great question. Collaborative decision making is paramount to most software development. I want to clarify a point here right away; when I say collaborative decision making, I don’t mean consensus building, which is often not beneficial. I’m referring to tools and techniques that foster collaboration, but also allow for dynamic self-selection of teams/groups. I think an important component to collaboration is figuring out who actually needs to be part of the process and accomplishing that through self-selection rather than delegation.
But your question was how important is it. And I say it is paramount to most software development because most software development these days is a design and discovery process. We have a notion of what we want or need, but we’re learning about the actual solution as we go along. And here’s the really difficult bit – the thing we build in an attempt to figure out what the thing should be changes the thing itself. In other words, the actions we take in an attempt to figure out the solution change the solution. So the solution is necessarily emergent – we not only don’t know what it needs to be, but it shifts as we attempt to figure it out. Emergent contexts are complex and complexity is best managed by diverse groups of experienced individuals working together. They need to work together to interpret the outcomes of their efforts and decide what to try next. No one of them can know all the answers and not all of them need to be in every discussion, so they need ways to figure out who should be in what discussions, how they’ll make the decisions, and when they’ll revisit their experiments.
Q3. What’s your take on ‘one on one meeting’? Are they really effective? How can we prevent it from a failure?
Doc: One on One meetings can be a very valuable tool, when done well. One of the biggest problems I see that these meetings get reduced to a status update with the manager being the primary recipient of “value” from the meeting. That’s all wrong. Status updates should be happening in another forum entirely and the primary recipient of “value” from the one on one meeting should be the employee.
I have a basic structure for one on one meetings that I offer to folks who are looking for some guidance. The whole thing is available on my blog at http://docondev.com/blog/2013/03/one-on-one-meetings, but the general structure is to open with a review of the things you agreed to move forward last meeting, allow the employee the majority of the time to share anything they want, allow the manager a smaller amount of time to provide news, asks, and action planning, and close with establishing an agreement of what you’ll move forward between now and next meeting.
It’s pretty straightforward and has worked for me and others for many years.
Q4. Please describe more on ‘leadership team is an indication of dysfunction’.
Doc: Ah, yes. The tweet that lead to a blog post. This is actually true of many of my posts.
In the tweet, I said:
The more I ponder it, the more I’m convinced that the existence of a “leadership team” is an indication of dysfunction. — Michael (Doc) Norton (@DocOnDev) February 6, 2016
The title of the follow-on post is, “Leadership Teams may be a Smell” (http://docondev.com/blog/2016/02/leadership-teams-may-be-smell).
I borrow the intention of the term “smell” from code smells. A code smell is a symptom that may indicate a deeper problem in the system. The existence of these smells doesn’t mean you have a deeper problem for certain, but you might want to investigate.
The smell itself, in this case the existence of a leadership team, is not technically a problem. A leadership team doesn’t prevent an organization from functioning. But the existence of a leadership team may indicate perceived weaknesses in the overall system. Maybe we’re attempting to compensate for these weaknesses by centralizing authority and decision making.
Our work is not simple. Much of it is actually cognitive work requiring multiple disciplines. Most of it is not repeatable and therefore is not readily proceduralized, regardless of how much middle management wants it to be. For this type of work, decisions need to be made by groups of skilled specialists who are close to (preferably performing) the day to day work. The further from the work the decisions are made, the less informed and worse the decision will be. Again, this isn’t simple work that can be managed from a distance through procedures and hierarchy. So if you have a “Leadership Team” at your organization, it indicates to me you have a collective of people far from the work who deem themselves leaders. So much so that they label themselves as leaders lest anyone forget. It smacks of hierarchy and authoritarianism – both of which are counter to collaborative experimentation which is paramount to success in complex work environments.
Q5. ‘Leadership and Humility’ is one my favorite articles written by you. It’s short, crisp and to the point. Please enlighten our audience about this topic.
Doc: Leadership doesn’t come from the title awarded to a person, it comes from the actions one takes and the character one displays. In this short article on Leadership and Humility (http://docondev.com/blog/2016/4/12/leadership-and-humility), I look at an HBR article (https://hbr.org/2015/11/we-like-leaders-who-underrate-themselves) that indicates people like leaders sho underrate themselves. I think it is easy to read this and think that people with low self-esteem are seen more favorably by others and therefore make good leaders. But I don’t think that is the case at all. I think that people who view themselves critically make for good leaders. That is not the same as being more critical of yourself or having low self-esteem.
A good leader is realistic about their abilities, seeks feedback regularly, and listens earnestly. When people provide redirecting feedback, a good leader sees it as an opportunity to assess themselves again from a fresh perspective and possibly make adjustments based on the advice and feedback from others.
Q6. Doers Decide. Tell us about one decision in your life that has been very difficult to take at the same time crucial to make.
Doc: Man, that’s a hard one. I’ve been through a good deal over the years. I’ve owned several businesses, sold some, and closed a few. And I’ve been in various roles from junior developer to CTO of other companies. If I am sticking with the “Doers Decide” mantra, I’d look at those types of decisions I made where I either exercised autonomy or fostered it in an organization.
Groupon is probably a good example of both of those things. I saw a serious lack of connection in the organization. Departments didn’t collaborate, products were insular, teams within products were siloed. I took it upon myself to do something about it despite not having the actual authority. I launched a few initiatives called “Interest Leagues” with the intent of creating more connection. I’d been talking with Ander Ivarsson from Spotify and Interest Leagues were my own version of Guilds that could exist without the rest of the Spotify structures. Each Interest League was also self-governed, fostering more autonomy. The members of the League decided on topics, meeting structure, when to meet and how often. So I made a decision to create a structure that allowed others to make decisions. Kinda meta, I suppose.
Q7. What is one advise you have for next generation leaders?
Doc: Be true to yourself, but don’t be selfish.
Put others first, but don’t get taken advantage of.
Foster Autonomy, Connection, Excellence, and Diversity.
Keep learning. Keep teaching.
Michael Norton (Doc) is a software delivery professional working to make the world of software development a better place. His experience covers a wide range of development topics. Doc declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise.
A frequent and well rated international speaker, Doc is passionate about helping others become better developers, working with teams to improve delivery, and building great organizations.