Following the recent ACM Tech Talk, Steve McConnell was kind enough to answer some additional questions we were not able to get to during the live event. The questions and answers are presented below:
Not a question, but each time I heard “They don’t allow me to do this” - my immediate question: Who are they?
I like this guideline for lower level staff, and it matches my experience in terms of vague perceived restrictions on things people can do. For upper level staff, I haven’t seen the case where “they” is undefined. They’re usually talking about their direct boss.
Where do you see the “software leader” fitting into a large complex organisation? Or is that a silly question?
There are different levels of leadership. I think leadership starts at a pretty low level with people who have influence-based leadership but don’t necessarily have any authority-based leadership. I’ve found that one key for effective organizational leaders is to understand the “influence hierarchy”, which for technical orgs is often more important than the “organizational hierarchy.”
In current environment, assuming talented engineer will move on to next opportunity, used individual growth (skills) as carrot to stay longer. Thoughts?
I agree. I think most technical staff perceive individual growth opportunities as positive and offering and supporting those opportunities increases loyalty to the organization.
I think your Make Decisions point is more clearly stated as separating strategic vs tactical decisions. Strategic decisions have ambiguity, are big direction/design changes, and ultimately you will never know if it was the best path, only that it met success or not.
I don’t know that this distinction adds a lot of clarity. I’ve spent a lot of time debating whether something is strategy or tactics. It seems to be always the case that one level’s strategy is the next level’s tactics.
I’ve found that sw leadership DOES NOT mandate documentation. IMO great method to expand awareness/exposure to team’s efforts. Thoughts?
Documentation has certainly fallen out of favor. I view documentation from a risk point of view: what specific risk is addressed by specific documentation? If the decrease in the risk is big enough, documentation effort is justified. If not, it isn’t.
I laid off an 800 person sw team, down to 200, and went on to survive. So many people hate me. I wish I were a sociopath…
Tough decision. The big question is whether the 200 survived by laying off the 600. If you hadn’t laid off the 600, would the company have folded and all 800 been out of jobs.
Regarding the communication, in my work I often find that stating what is obvious to me out loud is extremely important. The obvious has additional property that people hesitate to speak about it. However, if my set of obvious is different than your set of obvious, we can easily experience communication breakdown without knowing that it is there. I wonder what would be your opinion on that. Is being verbose a detailed useful?
I have seen this phenomenon too. Especially when you’re communicating across disciplines, what is obvious to one discipline is not at all obvious to another.
Can you say few words about managing up?
In a word, this is about training your manager, and especially about learning to communicated upward (and sideways) in language that will be understood by the upper level people. Technical people tend to drown executives in detail. A guideline I like is this: “You’ve been working on something for months, whereas your CEO has enough room on his/her mental stack for 3 short points. What points can you communicate to your CEO without causing a stack overflow?”
In the example of the starbucks card for working late. What would you suggest is a better way to show appreciation for the hard work they did?
Something that isn’t so easily converted to a specific number of dollars. Taking the team out for a team lunch or dinner, or bowling, or laser tag. The boss making dinner for the team. Giving out plaques or jokey awards that are personalized to each team member. Keep the acknowledgement at the social level, not the financial level.
Oops, hit return too soon. How do you convince technical leaders it’s worth their time to “become students of communication.” I’m working with one who doesn’t have a written status report, though he’s leading the key product delivery function for his company. How do I convince him it’s important enough to do, despite it being a “drag” or unintreresting?
To me this would depend on the specific personality of the lead who doesn’t want to communicate status. In generic terms, I would probably start by walking him through everyone who reads his status report and what happens in that scenario, then contrast that with walking through what happens when they don’t get a status report, and what happens in that scenario. He may just not have a good enough understanding of how information flows through the organization to understand what happens when others aren’t informed by him about what’s going on.
Part of manager job is to evaluate… how does that work if we treat them as volunteers? They can choose to be less engaged if they do not agree with management direction, even if it is right and must for business.
I don’t think it makes any difference. In volunteer organizations people are often asked to do things they don’t especially want to do. But they’re bought into the mission of the organization, so they’re willing to do those things for the greater good.
What’s your opinion on servant leadership? Is that akin to management based on your initial point?
I think the idea of servant leadership is a valuable idea, but I don’t see it as the same as the points I tried to make in this talk.
Any advice for when managers do not take the responsibility and instead make employee(s) responsible.
“Taking responsibility” does not mean micro management. The concept of taking responsibility is more about being alert to vacuums in responsibility where no one is taking responsibility, and being quick to jump into the vacuum. This does not preclude lower level staff from doing the same thing.
The phrasing on the question of “make employees responsible” sounds almost like blaming, which I see as a different concept than my notion of taking responsibility.
How do you empower Software Developers to take more ownership in the entire SDLC process and not just be “coder dudes”?
This is the $64 question of my whole career! The best answer I’ve found is to appeal to a sense of professionalism, and try to help them understand that to be a truly professional developer they need to become more than coder dudes.
What would be an objective evaluation of leadership and management performance? Over decades I’ve seen only some leaders that stand out
In generic terms, seeing how a leader rates according to my 7 unbreakable rules would be one possible evaluation. In more specific terms, I like balanced score cards (or OKRs or MBOs, etc.) to support more specific performance evaluation.
My question about ethics, diversity, inclusion was about the role of leadership in a company given the power dynamics in the surrounding society that privilege those in power and systemically make life much harder for marginalized communities.
I don’t really see this question the same way. I think for most of its history the software field has been wide open to anyone who wants to work in it and is willing to invest the effort to become competent.
The issue with diverse representation in software developments jobs has almost nothing to do wtih hiring; it’s mostly about the available labor pool. If you want to solve the issue, you have to solve it beginning in middle school, when girls begin to self-select out of STEM curriculum. By the time you get to college it’s too late (read the Taulbee survey, in case you aren’t already familiar with that).
I think there is a role for companies to play, if they want to be socially conscious, which is to encourage female and minority staff to volunteer in the schools in STEM roles (e.g., as tutors, robotics coaches, math team coaches, etc.) and serve as visible role models for young people. And of course ideally companies will support these volunteer efforts by giving (some) time off, and so on.