Hacker News new | past | comments | ask | show | jobs | submit login
Software development requires servant leaders (adl.io)
475 points by mooreds on Aug 15, 2018 | hide | past | favorite | 197 comments

You have to be careful being a servant leader. It's often a thankless job. And most of the time other people will be taking credit for your work. It's not noble to suffer like that -- it can be damaging to your health.

It's an effective position however and comes with it's own rewards. I personally relish seeing my team grow and the people I help mentor flourish.

I recommend getting a good therapist and taking small, frequent vacations. The trade off to being a servant leader is basically an environment that will wear you down. If you have conditions they will be amplified. If you don't take care of yourself you will develop conditions.

I think part of the challenge is fostering a culture in which people are discouraged from taking credit for other people's work; e.g., doing so is seen by most as being tacky and tasteless. That is a different culture from one that prevails in many American companies, where the rewards go the other way. But I think it's one worth striving for.

Teamwork. The word you’re hunting for is teamwork.

Fred Brooks was wrong. We shouldn’t be like surgical teams. A couple of highly trained egotists taking credit for everybody who spends all day cleaning up after their messes.

Software is a team sport. Might be worth looking there for inspiration. Except for the PEDs. Maybe we can skip those. Caffeine is the only one I’ll do.

You can be a servant leader and still take credit for things. Servant leadership is about enabling success, not sacrificing one's self.

Sure there is a notion the time taken to help someone is time taken from helping yourself, but if management doesnt view that as a global optimizing act, you've bigger problems

Maybe I've been lucky, but I've always found these principles to just be an effective way to enjoy life, build a great team and maximize business value.

Every day, I get to check in on my team and figure out how I can help them to be happier while also delivering more value to the business. And I find the longer I do it the more great surprises I get and the less I actually need to do to build and manage the org.

It's all I've ever wanted to do since I first heard about it in Joel in Software many years ago. The people side of Software Engineering is immensely more rewarding for me than the technical one. It's so satisfying to watch new hires in particular grow and get comfortable. Sadly, I don't often get to do it, and am usually pushed into more pure IC roles.

It's also really rare among companies I've worked at. Turnover is high and impressing people with flashy technology is key. Writing code that impresses is definitely the path to management. Those who sit back and try to understand the whole picture are viewed as uninterested. I've been consciously trying to get into more technical arguments because it seems to earn respect to have strong opinions rather than seeing both sides of the coin. Management (especially at the first level) is viewed as the person who evaluates other people's code and makes the best technical decisions.

The engineering side of that sort of environment burns me out more, especially as I get older. When I was in high school, sure, I loved to code, I loved the new tech, I loved experimenting with linux kernels and assembly and all of it. These days, it's just not nearly as meaningful to me as working with those around me. I know I'll never make better solutions as an individual than I would with a team around me. If I only get acknowledged for coming up with a way to run tests 90% faster or solve the weird rare bug nobody else could understand, my work life just feels incomplete.

However, engineering team management is chosen more on who can solve the problems the best, not who is the most interested in helping people. When I have expressed interest in management this is a very consistent message. Do you write the best code on your team? No? Then focus on that. This requires me to focus on the work I find less fulfilling - and be directly competitive with my peers. The exact opposite of what I want to do.

Maybe other people are getting credit for implementing the new flashiness in Clojure, but if they appreciate you clearing the obstacles to make it happen, isn't that satisfying? You get acknowledged more from below than above, and that's okay.

What I really want to know is, what's the suffering part of it? I've heard so many managers complain of not getting to write code any more - and been jealous and wanted to trade positions with them. You should get acknowledged from below, and honestly, if your next level management is good, they should see what you're doing as well. A lack of acknowledgement will always burn people out, but servant leadership shouldn't automatically mean that.

Could you please mention some particular example for which you'd be acknowledged from below?

Somebody who learns a new skill and thanks you for it?

Or - I know I thank my boss when I get to work on the things that I like, or when a complicated interaction with people outside the team is handled well.

Honestly it's really quite satisfying, just to unblock somebody. At the IC level usually it's small things like figuring out why the dev environment won't load or the tests keep failing, but they're thankfully and it's fulfilling to me.

When I was a Scrum Master, I found the role itself fine, and I could have done it for a long time despite the thankless nature you mention. Lack of monetary compensation for the job I was doing was what made me move on in the end, same as usual.

"Blessed are the peacemakers, for they are the doormats of life."

I heard this on the radio once. You have to be prepared to be walked on when you're the one keeping the peace.

This is an interesting article, but I do not agree with a number of its points. On the main one: servant leaders are not required; they work on some teams, and this is great. But other teams need a strong leader who knows what he wants and directs the execution. And team members are often OK with it when probed -- "he is an asshole, but sharp and gets things done. We rarely work long hours and are respected by senior management for delivering. I am not changing teams".

Many topics follow a theme: leave us developers alone, we are working. Do not negotiate with our estimates, etc.. This may not work in the real world. When a project involves several teams (one builds hardware, second UI, third computation, fourth preps algorithms and tools for analysis, etc.), there are common test events and mid-course corrections. Blowing past schedule affects others -- canceling a test event for a geographically distributed team is expensive.

In such cases when the developer says that they need an extra 2 months do X, "what can you do in 2 weeks" is a reasonable counter question. It may be an unreliable junk and those 2 weeks of work will have to be tossed and redone, but this may still be the best option in the grand scheme of things. Here developers often dig in and start throwing articles and links on technical debt; making them finally write a quick, limited capability prototype is a MAJOR effort. My 2c.

> ...making them finally write a quick, limited capability prototype is a MAJOR effort.

Fair, but why is that. I've been talked into just-for-now solutions over and over in my career. Rarely does the org actually go back and clean it up in a timely fashion.

It's possible, regardless of servantness, that leaders don't have a good reputation for following through and finishing things.

Rarely? Try never. Then its now your job to support the mess from now on. You can call me a recalcitrant developer if you want, but its like asking "Oh, well what bridge can you build in two weeks?"

Sometimes you should build a raft instead of trying to pretend you can build major infrastructure in no time flat.

The raft metaphor is a good one.

I've often used a similar one: "first we build a go-kart. It's a cool little go-kart, and will help us overcome certain barriers to adoption with a certain kind of customer for whom a go-kart meets their needs."

I find that the main arguments against the raft/go-kart strategy (from the the business leader) are along the lines of "we need a Ferrari man! not a go-kart; our target customers won't even consider a go-kart".

Its at this point that an very important discussion has to be had about how customer development and barriers to adoption are overcome. BTW - the applies to both new product development and features for existing products.

This is not easy. This discussion must include "Look, the experts who are building this are telling you ________ and ________; you can choose to accept that or continue down a path of uncertainty and investigation until they come up with another set of recommendations...". The goal for the technical leader is to setup a set of options for the business leaders to choose - none of which are allowed to be chaos.

If chaos is the norm, either the business leader or technical leader will be removed - or the business will likely fail due to that chaos and its effects on the team.

I don't know if this is a good time in history to be referring to "experts".

Hmmm. I understand why you say that - alas, yes in the political environment experts are cast negatively.

In the above context, I'm talking about the people we hire to do the things that need to get done to move a business forward - we hire them for their expertise and skills.

When I'm talking about the people I've hired - to management, peers in other groups etc - I refer to them as "the experts who are building the ________, tasked with accomplishing ________" and so on. It reminds people that they're here for a reason - to contibute ..and not here by random coincidence.

The market doesn't any longer condone leadership where finishing and following through matter the most. We're in a race to the bottom as we barrel ever further down an economic rabbit hole. I can't, therefore, blame "leaders" for the conditions you correctly point out.

That is 100% a leadership problem. There is a cult around Minimum Viable Product but that can be mitigated by technical leaders who are willing to stonewall the business leaders on unit tests and documentation. I don't even bother telling them that testing and documentation are separate tasks and roll it into development time.

Servant Leadership doesn’t mean you don’t hold your team accountable for their deliverables.

There's a big difference between developing yet another e-commerce storefront versus something that requires legitimate research and development.

Far too many confuse the two, and the discipline and flexibility needed for both.

In my experience it is rarely enough to just "lead" more thoughtfully, which seems to be what the author here is promoting. Software development does not just require servant leaders in the helping sense, but in the working sense. The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else. They have the power to move the project forward on their own, and working with them lightens the effort for everyone. Those who also adopt the ideas in this essay do foster the sensation among those they lead that they were never led at all, and rather achieved their common objectives together.

It depends on what kind of leadership we talk about.

Technical leadership: such leaders are often called architects. Of course they need deep technical knowledge.

Project leadership: such leaders are often called project managers or product owners. They only need shallow technical knowledge and can mostly lean on their experts in their team.

Human managers: they deal with personal growth and employment. They need enough technical knowledge to make employment decisions but need not be great programmers.

In large companies these are usually different persons. In a startup the CTO does it all, so of course he must be very technically competent.

I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if it was more than one person.

It does not always pay to specialize.

This. The dominant way software teams are managed seems incredibly bonkers and is not the norm in any other industry I know about. In the "real world", you have a boss, and probably he has a boss and so on. In the software world, everything is "negotiated" and "consensus-driven". Totally different people are responsible for hiring, firing, promotion vs. everyday decisionmaking. No programmer has a single boss, they have many, often implied and nowhere on an official org chart.

I think I understand how it got to be this way, and from a long-term professional point of view, it is probably good for programmers since it makes them less "cogs in a machine". It's also somewhat similar to "real" professions like lawyers, engineers (the kind with a title and professional responsibilities and, in Canada, an iron ring), and doctors, which I suspect programmers will ultimately become, thought it make take several hundred years.

Still, it can be maddeningly complex and seems like a lot of the time is too much overhead. On the other hand, a team is an engineered thing just like any other, in that there are tradeoffs. Management and capital largely seem to prefer predictably-scheduled software projects with accurate estimates to fast iteration and low overhead. One way to make this tradeoff is to have several clipboard-holders on a team looking at metrics daily, and spending 1 day out of every 10 in "sprint planning".

I should add that this "overhead" is, IMO, a good bit of the reason why other "professional" industries are so intractable to cost reductions, so long term the "professionalization" of programmers is probably bad for non-programmers (i.e. almost everyone) in the same way that the high cost of lawyer time is a disaster for ordinary people seeking justice (i.e. almost everyone), and the high cost of doctor time is a disaster for sick people (i.e. almost everyone).

For example, rarely does a firm just "hire" a lawyer and tell him what to do: they have to at least play along with the fiction that they are "junior partners" in a "partnership". They have professional obligations (to the Bar, for example) that are outside their employment obligations. It's not unreasonably for there to be more "overhead" positions for a practice than there are lawyers, because his time is to incredibly valuable that it makes economic sense for him to hire several paralegals and a secretary, not counting the "junior partners" that are employees in all but name. If lawyers were cheap (i.e. there was no cartel and fewer barriers to practice), the practice of law would look much different, and vice versa.

In most law firms, there are two classes of lawyers - employees (salaried, with bonuses) and partners (equity profit share). Generally, partnership takes close to a decade to obtain, and generally requires a buy-in into the partnership. The 'fiction', as you refer to it, is real - they are co-owners in the business, and should be treated with some level of respect. Generally, partnership structures are closely associated with the professional services industry as it more closely aligns with the industry structure and how work is delivered - teams are often cobbled together out of the firm's employee resources, and work is overseen by one or more of the partners. As teams may be of varying sizes, it does not make sense to chain individuals to a specific 'boss' that they may or may not be working with.

Right, and this model is itself monstrously inefficient and a result of 19th century (and earlier) modes of production persisting due to the presence of a guild and the absence any reform in the legal system. This is how furniture making and shipping used to work too, but then we invented factories and wage labor.

Any sort of consulting work is effectively a bespoke product - I don't see how you can get to the point where you can 'mass manufacture' professional services.

But people don't want "professional services" at all: they want justice for the vendor who ripped them off and skipped town. They want a divorce. They want to make sure that, when they die, their daughter gets the house. They want a partnership agreement for their hot dog truck business. Later on, they might want to make sure that their partner doesn't skip town with the truck and stick him with the debts.

These things don't necessarily require professional services. They certainly don't require taking time off in the middle of the day to go to an oak-paneled office with potted plants and an anteroom. We could organize our society to give people justice without traditional law practices. We've chosen not to because the benefits accrue to a well-connected minority and the downsides accrue dripwise to the rest of us.

Note that LegalZoom and a few others are indeed trying to do this, but even they are forced to equivocate that they're not really lawyers. It's the legal equivalent of making tobacco companies put diseased lungs on their cigarette packaging, except it's not correcting for an externality, but imposing one. Why do I even need LegalZoom for a will? Shouldn't there be a government website where I can register my will for free? Should I need a lawyer and a judge to give me a no-fault divorce?

To be perfectly honest, a lot of your complaints sound like, "Why do I need someone who is an expert in plumbing to fix my pipes?" "Why do I need someone who is an expert in medicine to diagnose my illness?" "Why do I need someone who is an expert in development to develop my software?" And the answer almost always comes down to, because they've been doing this a lot longer than you have; they've been studying it more, and they know more about the pitfalls and potential issues than you do.

> Why do I even need LegalZoom for a will?

You don't. You can hand write it on paper.

> Shouldn't there be a government website where I can register my will for free?

Registering a will is mostly a fallback to let people locate it.

> Should I need a lawyer and a judge to give me a no-fault divorce?

If there is nothing in dispute, you only need a judge (because a divorce is a court order.) You may need a lawyer to sure that your settlement achieves what you want, or to deal with disputes about the resolution as to property, etc.

Of course it makes it easier to have all three roles embodied in one person, but these are very, very different skill sets. In asking for one person who's good at all of them, you're talking about a seriously exceptional human being. There just aren't enough to go around.

I'm not saying reduce the body count, I'm saying don't specialize. If you have three managers, have them do everything, don't fire two of them and give the third one the work of the other two.

If you still disagree then I think we have different intuitions about the difficulty of wearing different hats in management positions. This is somehow analogous to the split on full-stack vs. specialized development. Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.

> Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.

The only caveat to this statement I'd make, based on my own experience, is that for the most successful full-stack teams I've known, having at least one of the team members dedicated as a front-end specialist is a major advantage. Someone who is honestly interested in the State of the Art and who is well-versed in the associated tooling and patterns.

They may decide, pragmatically, to work a step or two behind the bleeding edge with their production projects, but they understand what is out there and how that knowledge can be leveraged to help their team succeed. This role acts as a force multiplier and can empower the rest of the team's full-stack developers to build accessible, usable interfaces.

> Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.

I agree with that. The way I think about it is that in web you benefit from thinking about a system holistically. The divide between front vs back end is merely a technical detail, and an organizational structure that mirrors that divide has a strong potential to artificially create friction between two parts of what should be a whole.

Beyond that, I personally feel more empowered to take on responsibility as a full-stack dev, compared to when I was previously focusing on just the backend. For me, I think it’s mostly a psychological shift: I have more confidence to focus on solutions instead of deferring responsibility and thought power to someone else because it’s not my domain.

So, while full-stack may be a generalist (which for some is a pejorative) in a technical sense, I see the general technical acumen as just one aspect of a higher level, more intangible specialization: solving problems and getting shit done.

That sounds a bit lofty but I think it has analog to the bigger conversation here about managing.

Manager with holistic responsibility for a project > manager with isolated responsibility for a single aspect of a project.

I don't think I disagree, but I'm confused by your clarification. You mean that all three managers should perform all roles; some sort of managerial council?

> The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else.

Technical and programming skills have very little overlap with successful team management skills. It's the very essence of the Peter Principle.

I would say they have little inherent overlap, but they are not mutually exclusive. A leader can cultivate both skill sets. I think the problem arises because as we advance in technical skills, it is an incremental advancement over years. However, switching to a leadership role brings on a large, deliberate, fast learning curve to pick up brand new skill sets. Many new leaders just keep learning incrementally, taking far too long to get good at their new role. But the ones who do make a fast jump, and actively pursue their missing skills, tend to be great people to work with.

Teaching skills are the bridge. That's what servant leadership is to me - not teaching in the "stand in front of the classroom" sense, but teaching in the "lets pair on this and figure it out together" sense.

Sure, but team management skills often have no application without technical skills to give them context. The best leader in the world (whatever that means) will be severely hampered if they don't understand the problem domain.

Management and entrepreneurship can be learned. That's what MBAs are for.

Hell, the only reason I know what servant leadership IS is because I took a business degree about 10 years into my software career.

The best leaders in software and technical domains are also those who can write (either code or ideas) better than anyone else.

Do you really believe that? When you're interviewing someone to be your manager, is that what you look for? I don't. I look for communication skills, career development ideas, and evidence that they stay cool under pressure. Software development experience is definitely a plus, but I don't look for someone as a manager who can code better than anyone else.

I don't consider managers to be the leader of software teams.

The best managers I've worked for knew how to navigate the bureaucracy and politics of a large company and had next to no technical talent.

The best leaders I've worked for knew how to get shit done. If anyone dropped the ball, they could pick it up and score the points.

Definitely there's a need for leadership outside the scope of management, but the paragraph just above the heading "What Servant Leadership Means for Software" gave me the impression that this article is about engineering managers.

I look for all of these things as well, and they are critical. But none of them have any relevance in a technical domain if the person who has them isn't capable of pulling more weight than anyone else. Management is only approximately a learned and transferable skill. At the end of the day, lack of capacity in the target domain will make any managerial knowhow useless.

Also to be clear, I'm not talking about software development in the mythical man month sense, but systems thinking and a facility with abstractions and math combined with the ability to make such ideas real. Such people have the power to lift everyone up to their level, guide the group along an easy path, and fill in the gaps in ability present in their team.

There is a reason that people learn martial arts from people who have developed skill at them, not those who are good at managing workouts. The latter will only teach you how to manage your workouts. If you want to learn an art, learn from a master. In technical domains the masters are the best leaders, and you learn from them in every sense.

Martial arts are an individual pursuit. Software development is a team sport, which is precisely where your analogy falls apart. The best boxing coaches are not the best boxers. The best football, basketball coaches, sure, they may have experience as players, but you don't see the best players consistently go on to become great coaches. That's because leadership and coaching is a different skillset. I agree with a lot of e folks in this thread that perhaps the best combination here is a good (servant) leader to lead the team as a group, and an individual like a tech lead to train up on technical skill.

Being able to "write (either code or ideas)" is critically important to communication.

I don’t think these are exclusive. A technical lead should be able to write a proof of concept and support its evolution into a MVP by a team, fading in and out when required. I think the value of the article is in arguing that the ego typical of leaders has no place in engineering.

I disagree with this entirely, its basically the opposite of the point of the article. It sounds like the kind of leader that would have to insert their superior technical knowledge into every decision the team makes and who won't recruit the best people to take technical leadership of different aspects of the project.

Maybe we're envisaging different kinds of projects here. If it were 3-5 people building some component I'd expect there to be a technical leader in that group that can push it forward, as you say. But even they might not be the 'best' coder, whatever that means.

A 50 person project is never going to have a single person like that though.

Why does software industry keep coming up with this sort of thing all the time? I worked as structural engineer before becoming software engineer and we never had to invent different kind of leadership and procedures or change office floor plans or hire outsider non-engineers as our (scrum) masters, or talk about the client as stake holders etc.

Sorry about hurting your agile feelings!

Because structural engineers work primarily with other structural engineers, or maybe (real) architects at best. You were insulated from the ultimate 'customer' by at least one layer of profession, maybe more. You were also doing work that was safety critical which meant you had the final call and final veto, always, because you could say "that won't be safe" which is a debate-ending move.

Software engineers get to do "engineering" where they don't control their own deadlines, can be forced to launch at arbitrary unplanned times, where the customer can't explain what they want and what they want is always changing anyway, and they are effectively disempowered to fix any of this because they posess no debate-ending move like other forms of engineering do. And many other fundamental problems that make it a different kettle of fish altogether.

It sounds like you're saying it's different because there's inherently more customer interaction with software, but I think that's not really it.

Take for instance a car company. The mechanical engineers designing camshafts won't have a scrum team, but the people working on engine software probably do.

Structural engineers do not work primarily with other SEs. They have to collaborate with architects. Architects tend to take lot of artistic freedoms when designing a structure. We get to tell them to shove it as implementing some of their artistic designs would involve defying gravity and other laws of physics. Although that doesn't work and then you get failed/delayed/extremely over budget project

SEs also work with civil engineers/site supervisors etc.

No there's no veto resides in hands of engineers in any industry. There's a reason why bridges collapse and buildings need to be tore down for safety. It's not because engineers got to decide what's right.

Can you show me cases where a bridge collapsed because the engineers on the project said "this will be totally unsafe" and were overruled by non-technical business managers?



There are many more, but the fact that engineer's safety concerns were side stepped rarely sees light of the day after disaster strikes. Also it doesn't have to be a catastrophic failure. Sometimes the reduction of life span of a structure is cause of not taking care of all the concerns.

Also this does not stops with construction. Have you not heard about problems in cars or other engineering projects where safety concerns were ignored. If not, I have to ask you how old you are.

The first story doesn't seem to support your point. It's talking about engineers saying a bridge was unsafe after it collapsed. Whilst a FIGG engineer seems to have reported that the bridge was collapsing two days before it did, what I'm talking about is where a senior engineer i.e. chief engineer on a project says "this design is not safe" and is then told to build it anyway, or where a bridge isn't finished on the day that was expected and then traffic is put on it anyway whilst the builders are still working. People realising they screwed up after disaster strikes is normal but unrelated to project management discipline.

The second link has the same issue - the engineers cited as saying something is unsafe are saying that after problems are spotted and they are not the same people who built the bridge. Sure, anyone can say "that was clearly unsafe" after the fact.

To repeat, what I asked for is cases where the engineering management of a project said "this is not safe" at the time they were being told to build it and non-technical management then overruled them and put traffic on it anyway, that is, the engineers were not allowed to complete the job to their own level of safety satisfaction.

Hey man, as someone who also formerly worked in a different industry, thank you for raising this question. The longer I'm in software development (six years now) the more confident I am that all the varying rationalizations for this stuff are complete BS.

Please keep raising these questions so that those of us who don't believe in bizarre guru-based project management approaches can have a home in this industry.

It's not a bad question to ask. Structural engineering as a profession has also existed much, much longer than software development and with that comes new lessons of doing things better - perhaps at the expense of forgetting some of those problems have already been solved elsewhere.

It's as if our industry has this undercurrent of desire to reinvent the wheel instead of learning from what history is so good at teaching (providing context). No idea how on the mark I am about this.

Well, because we develop more value than structural engineers faster than they do and have killed far fewer people than they have. Essentially, we’re economically more efficient so a 10% improvement in our performance is huge, while a 10% improvement in structural engineer performance is a waste of time for the cost incurred.

Therefore, software engineers get a lot more attention in terms of how to increase efficiency. The difference is akin to why there’s so much work to get CEOs to be more efficient but not that much work to get janitors to be efficient. It’s not a value judgment. It’s just economical reality.

A less glib way of putting this is that in structural engineering construction costs dwarf design costs, while in software engineering the reverse is true.

If your construction phase consists of "type 'make' and grab a coffee" and the most expensive part is the coffee, then any efficiencies you can find in the design process will make a big difference to your bottom line.

If your construction phase costs tens of millions of dollars, you'll want to invest in designing more efficient construction methods rather than worry about tweaking the design process.

Sure bud! "We" developing more value (whatever that means) is equivalent to that of a stock trader on an open outcry floor thinking they develop country's economy.

Market value, not the abstract concept of value. Stock traders that make lots of money definitely count as developing more value in the sense I was talking about. That is, money earned to the firm.

Software is incredibly open ended. Maybe even more open ended than writing in English because software can be written in several languages or even in brand new ones.

The lack of natural structure in the work means communication and collaboration among the development team(s) is all that more important.

Structural engineering, or any other kind of real engineering (which includes every time of engineering except software "engineering") can also be reduced down to pure math. It's complicated math, and not everybody can comprehend it, but what engineers do boils down to lots and lots of equations. The only place this really applied in software is in efficiency calculations: is approach _x_ faster than approach _y_? In general this is considered a waste of time by most of the "stakeholders" (that is, the people who are signing the paychecks), at least until it's too late.

Software engineering can be reduced to math too, for example functional programming is a lambda calculus derivative. I think it's basically just that we're so close to programming that it's hard to see it for what it is, just a bunch of rules and equations.

That's just one facet of software engineering. Large swaths of it cannot be reduced to math ie everything the user actually sees, hears, perceives, etc. Those are subject to psychology, aesthetics, ergonomics ... Although we're trying to quantify those, too, so maybe one day ...

If you are choosing multiple languages for a single project or Keeping your project "incredibly open-ended" no amount of methodologies is going to stop you from going over the cliff.

Hey, I've been in software forever. All this scrum, agile, new fangled terms is just work. Call it what you want, but it's all just work. Do work and you'll get done, no matter the process. Do great work and you'll never have to look at it again.

Go you.

This was the only comment you made in 8 months. I feel honored!

I can't stand the phrase "servant leader". You can have a "good leader" without any other adjectives. The word "servant" is a loaded word in a way.

And, has anyone heard of a "servant" that works just under the "servant leader"? Kind of a meta-slight against any group to be blessed with a "servant leader" instead of just a good one.

Edit: Consider flipping the phrase, "Leader Servant". Now hopefully the silliness and almost meaningless title this really is.

Also, I've heard this used by leadership to justify their abusive behavior as well, so titles mean nothing, actions mean everything.

I disagree that the phrase is meaningless. This leadership philosophy is very different from traditional Western ideals of leadership, though tbh I don't think the article did a very good job describing it. I first learned about it from the best leader I've ever worked for, David Cancel (CPO at the time). I absolutely considered myself blessed to have the good fortune to work for someone whose primary focus was making my work easier, rather than wringing every last drop of efficiency out of me. Perhaps it's a difference that one needs to experience to appreciate.

>This leadership philosophy is very different from traditional Western ideals of leadership...

The crux of the issue. You can't label a western leader with an eastern ideology and thus "make it so", that's called lying.

Actions speak louder than words, and labels aren't needed to prove reality.

I think (correct me if wrong) you have interpreted the phrase "servant leader" to mean "a leader of servants". Rather, it's intended meaning is "one who leads by being a servant".

No, I interpreted the implied meaning behind the phrase, it's just as meaningless either way. "One who leads by being a servant" is a non-leader, it's an oxymoron, maybe that should have been my phrasing.

Also, it smacks of false humility. No one would call themselves a "servant leader" if they were actually a servant, they would just say "servant". Anyone who calls someone else a "servant leader" is choosing their words poorly, due to ambiguity. (what are you saying about this person if you call them a "servant leader"?) It's an absurdity, it's meaningless double-speak.

The paradox in terms is entirely intentional. It is supposed to make you stop and think, "How can this be?", because it pushes back against many qualities often traditionally associated to leaders. So in fact, I stand corrected, and the phrase has done it's job in communicating to you exactly what was intended. It is not meaningless after all!

(Also, I agree that to self-identify as a servant-leader is not a humble thing to do. But that's true of self-identifying with just about any virtue.)

Good leaders don't need labels, only false/deceptive ones do.

While I appreciate the absurdity of your counter argument I really doubt that corporate management is intending to be vague/confusing for the sake of instigating discussion or thoughtfulness in the title of mid-management.

Ever heard of a CEO being called a "servant leader"? If so, who gave him that title?

Again, my personal experience is abusive leaders using this to force underlings to view them as humble, or even lowly equals, to quell dissent while demanding fealty and strict obedience.

Have you ever seen even a single instance of a made up title making someone a better person?

>> I really doubt that corporate management is intending to be vague/confusing for the sake of instigating discussion or thoughtfulness in the title of mid-management.

I wish I had a source to quote you, my google-fu is failing me now but there's a school of thought that, in a mature organization, the primary role of the executive leadership team is to manage corporate culture. If the leadership team is trying to foster a culture described by the term "servant leadership", then they definitely would want to provoke discussion of what that looks like and how that's different than other organizations and cultures people have worked in.

I believe what you are thinking of is https://en.wikipedia.org/wiki/Reverse_hierarchy

>...in a mature organization, the primary role of the executive leadership team is to manage corporate culture.

With deceit, propaganda and manipulation tactics?

> The idea of “servant” leaders has been on the rise in the agile community of late. Robert K. Greenleaf coined the term in a 1970 essay, but the idea is timeless.

At least in German, that term is arguably much older, going back to the Prussian king Frederick II, who wrote "the sovereign is only the first servant" ("The sovereign, far from being the absolute Master of the people which are under his domination, is only the first servant").

With all due respect to Frederick II, the servant leadership goes back at least to Jesus of the Bible:

"...let the greatest among you become as the youngest, and the leader as one who serves."

Luke 22:26

One can trace it back to ancient China and ancient Greece too:


Sure. That's correct for the general concept, but I was refering to the actual use of the name for the idea in German, because of the well known quote.

It's also similar to how the pope & bishops refers to themselves during liturgy. All Masses include a prayer for the bishop(s) and pope; when the bishop is the celebrant, he refers to himself as God's "unworthy servant", and if it's the pope that formula morphs to "your most unworthy servant".

Pretty sure that the word servant had its origins from Latin (servus).

I think they're talking specifically about "servant leaders", not servants in general.

The Roman emperor was known as "princeps civitatis" aka "first citizen".

The language obviously implied the emperor was just the first among equals, although more a political framing than actual attitude held by emperors.

It's very clear: the Prussian mention is to the origin of "servant leaders" and not referencing the origin of the actual word "servant".

Obviously I meant the idea of a leader as a servant, not the word.

Wasn't so obvious to me. Sorry, I misread it.

I experience "servant leaders" crash and burn. It's often done so poorly. They never make decisions, they just keep making vague requests for the team to come to a consensus and it's chaos. Also, another con of servant leaders is that they often don't hold people accountable. Bad behavior on the team starts to spread and moral tanks. Yes, the concepts of a servant leader sound nice, but it's often implemented horribly. Sometimes the leader needs to be aggressive, make unilateral decisions, and hold people accountable.

I agree with your point entirely. In practice, the software industry seems to be rife with a cult-like worship of humility and team consensus. So much so that consensus and humility have lost all meaning! Leaders should naturally rise for valid reasons, and their decisions and opinions should also naturally have more weight to them.

I'm all for letting the little guy get a seat at the table, and I'm all for hearing out people's ideas, but at the end of the day, someone has to make the call. That should be the leader's role. The leader will ultimately take the fall if their choice was incorrect, so the team should trust them.

The best companies I've worked for have had decisive leaders who cut through the nonsense ideas coming from their team (respectfully of course).

You’ve setup a false dichotomy. Servant leadership can & should be decisive.

Sure maybe there's a "right way" to be a servant leader. I'm telling you how it's often executed in practice...which is poorly.

I think that's describing no leadership rather than a variety of it, but yeah most leaders suck, especially in software

Maybe. I think there’s all sorts of leaders and all sorts of ways and configurations projects can have.

IMO the most inspired software is the implementation of the vision of one person who had an artists/visionaries clear idea of what they want to create, who listens to input and brings in new ideas from others, but has absolute control over the decisions.

Servant leaders of software projects I’m guessing has the potential to lead to somewhat ordinary software.

There's no one-size-fits-all management style. Evil megalomaniacs can also have success.

It's good to have humility, but that's true for individual contributors, not just leaders.

As you point out, if a leader is too humble, at especially at Big Corp Inc, products can end up designed by committee, an ugly Mr. Potato Head that everyone hates.

It'd be nice if success required 1-3 specific personality traits but they can't be correlated exactly. But this kind of "If you do/have X, you will succeed" articles will probably always be popular.

> There's no one-size-fits-all management style.

I guess someone has to tell the Agile people, who are obsessed with rules and formalisms, about this.

Leaders need experience to cope with different situations. If a team wants a good leader, it should choose him/her based on his/her successful projects instead of relying on FotM Agile concepts and the candidate‘s willingness to adopt them.

Obsessing over any rule pattern, whether it's Agile, Lean, Waterfall, etc., is, of course, stupid.

Those patterns are designed to help groups work together more efficiently, not lord over them like the gods of Olympus.

Assuming you've already explained your frustration to your manager, might be time to seek a new opportunity...

I think the difference in software engineering is that the cost and time of digging a tunnel is almost zero. When you write code that "digs a tunnel", writing the design and code are the hard part, distributing the compiled code is usually predictable and simple. So I think software engineering is closer to the planning phase in civil engineering, where you need to go research the mountain, plan multiple routes, deal with regulation, etc. I bet it is also hard to estimate in civil engineering how long it's going to take to complete the plan to build a tunnel.

Man, the first part of the article hits close to home. Ik currently in a project where there's a combination of scope creep and inexperienced developers causing the work to take longer than expected. Business however is unwilling to move any deadlines.

> When the business side “wins”, the developers end up in a death march.

This is a pretty good way to describe what I feel like now.

The term for this is "developer abuse".

This is the sort of article that makes me imagine a dialogue between a senior software engineer and a newb developer that goes something like this:

Newb: Hey man, I think for this project I'll write my own SQL datastore from scratch. I've looked at a bunch of them and my project, which is basically an inventory management system, is such a special snowflake that it needs its own datastore.

Senior: That would be insane. Never do that. Use what's already out there, and is tried and tested. In fact, just use postgres and make it work.

Newb: Aw, ok. I was so much more excited about writing a new SQL datastore than I was about the actual project it's for, but sure, I'll just use postgres. starts to walk away...

Senior: Hold up a sec before you go, I want to run something by you. Because our discipline, which is basically a team of people who are hired to build things on a schedule, is such a special snowflake, I've invented this totally new way of thinking about work, and of organizing a team and leading it, and there's a bunch of new terminology and I have some cool diagrams... I'm lobbying that we all switch to this at the end of the month.

You just might not have experienced decent leadership.

Servant leadership doesn't mean you do what your reports want. It means you enable your reports to make good decisions, instead of deciding for them. It doesn't mean you don't teach, or you don't share experiences.

Let me quote from the original: "The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?“

Do you think the senior can answer "yes" to this if they just acquiesce to everything?

I think GPs point was that building cohesive teams is a known art and yet software folks keep trying to reinvent the wheel.

I did an MBA, and have built and led software dev teams for decades. Just to establish my bona fides, because the "known art" of building cohesive teams and what actually works for software teams is definitely two different things.

Actually, having talked to friends in other creative industries, I don't think anyone gets this right for creative processes. And I think TFA gets it completely right when it talks about estimation as the root of the problem.

We know there is no method of correctly estimating software development timescales before the development begins. This is also true of other creative processes, but usually they have the ability to ship a half-complete product. Think of writers meeting a deadline with something they know isn't "right" but doesn't actually burn the reader's eyeballs out of their skull. Or graphic artists who have to send something off that they know isn't great, etc.

Software actually is unique in this respect, because it doesn't work if it's not complete. There are bugs that need to be fixed, features that actually need to be complete, etc. While a graphic artist will usually get a couple of requests for changes, there are usually contractual limits around this. No such luck in software (imagine saying to your customer "you can report two bugs or incomplete features for free, then we start charging you again").

So the basic problem (as TFA says) is that estimates are never accurate, and yet businesses need accurate estimates to make decisions. A good software team leader/project manager/CTO/IT Director/Tech Wiz bridges this gap and manages both sides so that the business can function.

To do that requires empathic understanding of the needs of both sides. Authoritarian leadership, either from development refusing to heed deadlines, or management insisting on them, will (as TFA says) break the business. Servant leadership allows both sides to make the necessary concessions to keep the business afloat.

Awesome that someone has written this up so well :)

> Software actually is unique in this respect, because it doesn't work if it's not complete.

This is a point that really ought to be more broadly recognized. It's a pervasive issue throughout software development, and while the situation is improving I'm not convinced that's about any kind of improved design. It mostly seems to be a function of delivery mechanisms which can circumvent the problem - internet delivery of patches, automatic updating, and remote hosting of apps have all lowered the bar on "good enough to ship". The most obvious example is almost certainly video game development: planning and labor conditions haven't substantially improved, but the prevalence death-march development has been made much better by the ability to gracefully patch games after release.

"You can't ship a partial product" isn't universally true, of course, but building projects which can be shipped while incomplete requires planning for that option from the beginning, and has real tradeoffs. In general, software planning seems to either ignore this issue entirely and go vastly over schedule, or propose some agile/lean/extreme 'iterative' process without paying any attention to the requirements and costs of that approach.

Imagine telling a construction firm that you want a two-story 'minimum viable building' that you can work in while they add the remaining stories if things run over schedule. If they didn't refuse outright, they'd charge you double and design the entire process around that condition.

Actually, that metaphor seems like a pretty useful one. Both fields involve developing something which can't be delivered at intermediate stages, where iterative never-broken development is slower and more difficult, and where both unforseen (e.g. unmarked water main) and unforseeable (e.g. storm damage) problems can arise throughout development. And, consequently, both have a well-earned reputation for late, overbudget deliveries.

To be fair, we can all totally ship incomplete and buggy software to good effect. Imagine a shipping system where users have to submit orders and then manually update the address zip code--sure it is buggy but the end user still gets value.

People are too concerned with perfect software.

This is true, but it doesn't mean software can be delivered at any point in the development process.

Something like a novel is (hopefully) shipment-ready at most points from the first draft on. A full rewrite might happen at some point, but much of the development process happens after the first draft and can be interrupted with minimal cleanup. If you've only copy-edited half of chapter one, you can still finalize those changes and ship without trouble. And, you're unlikely to get 95% of the way through writing and discover an issue in Chapter 10 that invalidates chapters 2-6. (This does happen, especially with mystery novels, but it's not the standards outcome. It's much more likely to just hit a problem that makes you want to rewrite, rather than actually breaking the piece.)

A lot of software has a high percentage of work happen ahead of the MVP, and even if progress past the MVP is done while maintaining a working state, the individual tasks don't tend to be interrupt-able. If that shipping system is instructed to handle bulk-loading of 50,000 orders, fixing the manual zip code issue is probably still an all-or-nothing task. And, of course, there's a high chance of invalidating past work. If a contract comes in that requires multi-user ownership of orders, that might break invariants across the entire database while still looking to the buyer like "just adding another user to my order".

Pretty much any field has some minimum unit of work to move between acceptable states. You might print a novel mid-editing, but not while a sentence is half reworked. You can launch a new car model with fewer units finished than you'd like, but not (easily) with contracts for dealers that will be unfulfilled, and certainly not if you find a problem with the airbags.

Software development frequently gets planned like creative or social work which generally has small minimum increments and few catastrophic surprises, but ends up playing out more like construction or physical manufacturing where unexpected failures are likely and shippable states are noticeably far apart. Hence death marches, outright broken releases, and a lot of the other issues the field is infamous for.

Software folks reinventing the wheel is a problem that extends far beyond teambuilding

I can't think of another discipline like software engineering. Most other disciplines where you build things you reach a point where you deliver the product and then you're done with it, there might be some maintenance but the period of major changes is done.

In software you might have a building full of engineers working on the same product for years after it was initially delivered, adding major features, making deep changes. The level of continuos delivery doesn't exist in other fields.

Sure it does. It exists in construction. You build a building to spec, and then that building is constantly outfitted for new tenants, remodeled, and renovated for decades if not centuries.

Yeah, but the original teams that designed or built the building are long gone, and in many cases the tenant/remodel work can happen without any of the original blueprints. Buildings are meant to be modified, and this is why we have building codes, subfloors, ceiling tiles, etc. In commercial software, the startup hurdle is so great, that it usually means only a team that is contiguous with the original construction team can economically extend the original in a meaningful way.

Open source requires a different way of thinking about it; not all software can be open source. Not all buildings can be raised like a barn. In fact there is very little in the construction or civil engineering world that matches what happens in open source software.

This analogy is one of my personal favorites for software development. The machine that is going to be running the software could be considered our building. The hardware of the machine is designed to exacting specifications by people that typically hold university engineering degrees and is much more reliable than software typically is, it has to be or nobody would use it. Failure of the building is catastrophic to the tenants.

A process could maybe be considered a room within that building and adding functionality to that process is akin to adding furniture to a room, or I guess, doing a buildout for a tenant. You add specific furnishings to help you accomplish specific tasks within that room.

This analogy breaks down pretty quickly, but think about the room here. I can now explain to a non-technical person that this software (a single process in this case) is like a broom closet that we've shoved full of old furniture for the last 5 years. Prior engineers have stacked tables to the ceiling, filing cabinets have locks without keys. We don't even know what's in the back of the closet at this point, and getting a peak at what's in the back will require unpacking everything at the front.

On the other hand you could have a different room. It has doors for egress and ingress. It has glass walls so we can see what's happening at all times. We carefully arrange the furnishings for efficiency, and can swap out old furniture for new in a matter of moments. We regularly clean the room, removing unused/aging equipment etc... When people enter that room to work (end users) the workflow is effortless and intuitive.

So as a software developer/engineer or whatever you call yourself, we're more like the contractors that buildout interiors for specific use cases. We equip the rooms for doing specific jobs. You give us the building or even just one room and we'll make it useful.

Except that hardware fails, but software should stay reliably running in the face of that system.

Think of software more as a neighbourhood, or even an entire city. Rebuilding any given building should not impact the running of the city itself.

Software is the creation of the spec.

To a newb just using Postgres should be new and exciting. It's such a rich database I am still learning, even after years using it.

Maybe that was just a bad example. But I don't know, even just using old HTML and CSS to set the page is always interesting to me, because there are always problems to overcome. How do we make everything fit on the page without it being cluttered? How do we let the user do this thing that they want while also not interfering with this other thing that they say they want?

After many years, I like to use old, established pieces, but fitting the pieces together is what I find interesting.

At the same time, when I was first starting out, there was a greater urge to roll my own. I remember rolling my own diff program, in PHP. It was worse at diffing than figuring out how to safely pass the inputs into the shell, and just using good old diff, but it made me happy and it was a useful mental exercise. Newbs need to stretch their wings and see how far they can fly. Their flight is probably much worse than just hopping on the ol' jet. It's a hard problem.

A little bit beside your point but I like your example and agree with it.

In the example the Senior IS the Newb at whatever team/managerial issue is part of their new frontier. Unless they have experience to run those ideas by they don't have anyone to point them to "postgres".

I'm not sure the applying the ideas in the article requires Servant Leaders™ to explain to the people they're leading what Servant Leading™ is. I read it more as, if you're in a leadership position, here are some ideas which might make you more effective.

Was Steve Jobs a servant leader during the development of the original Macintosh?

In some senses, yes. For example, the original developers got to sign their work -- a way to say "We ourselves have achieved it!"

No software project I've ever worked on let me put my name on it.

Everything needs servant leadership. The whole idea of servant leadership is so unbelievably powerful that it spawned a religion that managed to convince the European world that there's a magical servant leader that was sent down to teach and serve us, and regular non-magical non-servant leaders killed him because magical leadership threatened them. People believed it, and still do to this day, because that's just the way people want to live.

A new doctrine isn't helpful. There's no new gospel to spread, the old gospel was good enough. The reason you don't see servant leadership everywhere in business is because people have different priorities and it's really hard to get them to line up. When priorities don't line up you need a class of people whose job it is to manage the disconnect and ensure that the people paying the salaries are getting what they're want, because the mismatch in priorities means they can't trust the ICs.

Servant leadership, being led by someone who has both your interests in mind, and who also thinks like you, would flatten the hierarchy so less of that ugly management business is needed. But the real answer to this dilemma, the other side of the coin of the rise of Christianity, is that you have to adapt to your masters. Christianity only became successful because they managed to become Roman, to embody Roman ideals and engage with Roman people. Only in this way could the cult of Jesus have spread so far that 400 years after its inception, it became the official creed of the Roman Empire.

A fact you miss in Sunday School.

Many other types of leadership can work just as well depending on the team.

The biggest downside to servant leaders is, IME, they split their focus and are often not held accountable.

For example if you prioritize growth as a servant leader are you held responsible if your team has a higher than average turnover? Are you rewarded if you have a lower than average turnover?

Is that more important than project success to the business?

Is this clearly defined anywhere for your project?

At this point in my career think the problem is always that somewhere in the chain of command is someone who sets arbitrary deadlines and then keeps changing the spec.

As an engineer I hated this- we would just get more and more work piled on us, arbitrary and counter productive of dienright stupid changes. Product managers who didn’t understand the user and would just throw random ideas in there without vetting.

When I got up to being CTO, I discovered my CEO didn’t give a flip about any kind of reality, just demanded more, kept making changes and wasn’t interested in hearing about how work related to schedule. He literally didn’t care that he made it impossible to deliver the product, and just blamed development (and eventually me.). My deal was structured such that I was ok being the fall guy but the abuse those engineers suffered was pointless.

This is not the only time I’ve seen this. In 20+ years I’ve seen it at companies like Microsoft and Amazon (from Bezos directly- the most incompetent CEO ever.) I’ve seen it at many startups too.

It seems non-technical “leaders” don’t give a shit about the fact software takes time. They think it should be trivial to change anything anytime.

Basically I’ve stopped working for other people because of this.

It’s not that software is hard to manage- it’s that MBA types have sero respect for the engineering department and just want to abuse engineers.

If you have a good situation it’s because somebody between you and the MBA asshole is protecting you. Or your CEO is an engineer.

My rule is, no more working for CEOs who aren’t real engineers (had done lie about that too. No your HTML page in high school without do much as a lick of JavaScript does not make you “technical.”)

Exactly! I just wrote a comment like this. When I work for "servant leader" leaders, the team often lacks direction and all decisions are made very inefficiently.

Much more important than being a servant leader, the leader needs to also be a developer himself.

Its the only way that the leader is going to understand the needs of developers in the first place.

Non technical middle managers make awful software development leaders, yet that is very common scenario in a wide range of companies.

The problem is that executives on top are just not comfortable dealing with developers directly.

All work actually requires servant leadership to be maximally effective. This article does a great job of explaining it in the software domain. My wife works as a school principal and though the specific jargon would be different, the lessons are the same, because other than specific idiosyncracies that engineers have, we're all motivated and burned out by the same fundamental things. That's the good news - people are people.

The bad news is that if you get burned out by software, changing careers isn't going to fix anything. As I get older I care less about the specific problems to be solved by the team, and I care a hell of a lot more about the group of people I solve them with

Thanks for posting this.

What the quoted paragraph doesn't show is the hiring process, "servant leaders" will only work if you hired the right candidates and provided initial guidance on expectations. Right candidates for the job at hand is _the_ hardest part.

My current workplace hired junior level developers who came through with very limited coding skill and but talked their way into permanent positions. They quickly hired consultants to "help" them with projects, and settled to become requirement gatherers and use the consultants to code all their stuff.

My point is, if you were to walk in as new manager in your group, kicking butt and firing people, and NOT be a servant leader, might work better.

It's not just software that doesn't "square the very definition of a project ... with our real world experiences". The same happens on the business side. There's always the other side of the equation: how the system reacts to what you're trying to do.

Perhaps some component doesn't really gel the way you had hoped for. The same goes for business opportunities. Sometimes it just doesn't work out and it can be a real blow to the project. And sometimes the users just aren't there or don't appreciate what you've done.

Management generally has to be flexible, not just in software, but in a lot of divisions. Because ... unknowns ... that are discovered as you go.

> It’s not because we’re narcissists who need special labels.

Whoa, let's not get carried away here.

Is there a word for the specific form of narcissism that thrives on getting ahead by pulling others down?

This captures my philosophy on software leadership better than i could have explicated myself. I was hooked when he started to talk about when we come up with different names for a project because we are never satisfied with it

There is a difference between a leader and a manager.

We never want servant leaders. We want leaders that embody an idea, have a vision, provide inspiration, and instill purpose.

We absolutely want servant managers. These are the people who allow those working for them to just do their job.

The lower on the org chart a person is, the more of a servant manager they should be and the less of a leader they need to be.

In smaller organizations, you can be both low and high on an org chart, as the org chart is flat. In such cases its good to embody both the leader and the servant manager.

I have been working professionally with software for almost 20 years.

And what I defintly can say is that great leaders do exist.

But it takes a certain level of integrity and intellect, IN the company culture.

It's bullshit that we're better, more bright and what not compared to other fields. We're absolutely not. We're comfortable being pushed around and then bitching about it, maybe because we have no integrity and are scared

"Servant leadership" is just another word for leadership.

Good leadership is a service. It's certainly rare enough.

But what people tend to mean with the phrase is the opposite: that good leadership consists of and is defined as service. That's just service with a "leadership" nametag, and is insufficient when actual leadership is required.

There seems to be this odd sentiment in the comments here that, unless you're an absolute tyrant, then you must be a weak leader, not directing people and not holding teams accountable. This concerns me greatly, because thinking that "strong leaders" have to be tyrants is a big part of what lead to the Maryland football tragedy.

From this article, IMHO these are the most important for [technical] leaders, in priority order.

All other things : trust etc - effectively fall out of these, because these are the things that will enable the business to move forward and encourage continuous improvement.

1) Have Empathy for the Customer

2) Have Empathy for the Customer

3) Have Empathy for the Customer

4) Drive Uncertainty Out of Requirements

3) Be “Chief Unblocker”

The easiest way to end up with "servant leaders" is for a worker owned co-op to hire management, as opposed to the neo-feudalist corporate structure to common today.

A "servant leader" who just decides to rule^H^H^H^H manage that way out of their own "enlightened self-interest" is incredibly patronizing to employees.

> Managers shouldn’t “negotiate” with the estimate

Well, the unspoken part of the negotiation process is, "ok, you said it was going to take two month but how long would it take if you worked 18 hours a day for the next 4 weeks straight? You are on a salary after all."

This can be applied across any job field. A good manager gets obstacles out of his teams' way so that they can do the best job that they can.

All good theories go out the door when your dev team is offshore. Read good detective stories for an inspiration: how to uncover lies, separate truth from bluff, trust no one. Considering how many projects are done by offshore teams - this article reads like a ballade to sunshine in the midst of a hurricane

While overall the article is interesting, I'm really disgusted by two sentences: "In software it’s common to have something estimated at a day take a week instead." and "The inherent inaccuracy of software estimates creates extra tension that you don’t find in other industries."

Oh, poor thing, you feel so special by being a software engineer?

Have you never heard of construction projects taking many times the estimated time/budget?

Maybe try digging a tunnel through a mountain, where the kind of rocks and caveats you find on the way can make you overrun your estimates? Maybe try sailing a container ship through an ocean, where a storm that appears in the middle can make your straight trip take a week more because you must go around? And we are not talking yet about building a subway line under a city, dealing with legal challenges, ...

Wake up, this is called a project, this is called risk assessment and risk management. It's maybe not done in your projects, but you don't need a fancy name for it, it's what has been happening for millennias.

While I agree with you that software projects aren't unique in having difficulty trying to estimate things, I think that emotionally it's different. If you're digging a tunnel and hit a seam of unobtanium you can go to your boss and point at the seam and say 'Look at this big rock - this big rock is very hard, we had no way of knowing it was here but now we know we have a problem". That is very different from going to your boss and saying "You know I was working on X, well X is harder than I thought, it's going to take longer". Well - is X harder? Or are you just slacking off? Or maybe you just took a stupid approach?

It's much more difficult to actually confirm that the cause of the delay is an external factor, rather than a reflection of the person doing the work since most likely the only person with a real understanding of exactly why something is difficult is the person doing the work. So there's a stigma attached that isn't present in other professions.

You will never know what you don't know. That doesn't change. The question is, what do you do about it? That tunneling project probably did account encountering different materials, but maybe not for unobtainium. If the area is known for unobtainium, that's obviously a research miss. If this is the first seam ever encountered within 500 miles, that's straight up unexpected findings. Most situations usually lie somewhere in between.

You can always do more research, but research is at the cost of getting things done. So you balance that, with the understanding that sometimes you will go into projects with too little research. And no matter how much research you do, you will occasionally get genuine unexpected findings while doing the work that cause you to stop and go back into research mode.

EDIT: I mean, just watch those DIY shows some. Almost every episode, there is something "unexpected". Foundation work, roof work, load bearing walls, pipes and vents in walls, electrical or plumbing needs updating, etc. And it rarely ever actually effects their timeline, because they've done it enough to model that something unexpected is probably going to happen.

I wholeheartedly agree. I think it’s however more of an unacceptable problem in non technical industries who hire technical workers.

For instance, risk assessment isn’t all that helpful if your deadlines are bumped up by weeks or months and the client or your coworkers or bosses have no concept of why the project “can’t just be done immediately” when you’ve planned for added weeks. Even worse when they don’t understand why they can’t suddemly throw new variables at you after all estimates have been completed like new, potentially breaking features. Last minute scope creep is a real problem in some non-technical fields because the whole software solution is often some “nerd magic” and there’s no desire to understand the problem or solution except where to click and can they have it all by the end of the week. Theoretically maybe it could be done, but there goes all window provided for unexpecteds.

Admittedly, this is probably more of an organizational flaw than directly associated with the subject at hand, but a very real tangent.

I usually try to explain this using a sporting analogy, because the people who treat this as a "nerd problem" usually understand and relate to sporting analogies.

Why can't you hit a hole-in-one on every shot on a golf course? You know exactly where the ball is, where the hole is, how far it is, which way the wind is blowing. All you have to do is hit the ball so it goes in the hole. It's definitely possible, there have been hole-in-ones on every green, so why can't you do that for this shot? Are you an incompetent golf player? Are there super-competent golf players who can do this on every shot? Why not? This does not seem difficult to me (but then I've never hit a golf ball in my life). Can you explain why you can't do this, but other people have done it before?

That's pretty good. Hope you don't mind if I end up using that or a variation in the future.

I'm not sure argument by reality TV is very effective. Obviously everyone tries to budget time for the unexpected. That doesn't mean it's equally difficult in all professions.

You are referring to non-engineering managers, which will also happen in other industries, this depends more on the size of the company I'd say.

Also, if you are really the only one to understand (if you are the only tech in a startup for example), then part of your job is actually to explain.

Problems hit by developers are imho the same kinds that you describe with rocks: something unexpected has happened, we didn't/couldn't see it coming because of this and this, we need to do/change this and this, ... or maybe the risk was already considered in the estimate.

One big difference I was thinking about is that in the software industry nobody dies if something goes wrong. In building a tunnel, or shipping or many other industries, if you don't consider the risks well enough and ahead, someone might die.

They're not even necessarily referring to non-engineering managers. It's often difficult to explain to engineering managers or other engineers why something won't work or requires more work/research if they themselves have not done the work. The engineering manager isn't even necessarily that familiar with the technologies being used or experienced in the specific problem being solved.

When digging a tunnel, there is a finite number of kinds of rock that you can hit. It's well within the realm of possibility that an experienced engineer is familiar with any of the rock they will encounter, even if they didn't expect to hit them when digging. This is generally not the case with software. Even as an experienced engineer you continually hit issues that you've never encountered before and don't know how to solve without spending a significant amount of time doing research or trying out different solutions.

The upper bounds of complexity are higher in software than construction. It's not narcissism, it's just the nature of that kind of work.

> The upper bounds of complexity are higher in software than construction. It's not narcissism, it's just the nature of that kind of work.

It's a wonder that it works so well in fact.

I think software is probably the most complex and difficult engineering humans undertake. If you think of all the ways that a program can crash, compute incorrect results, and generally go wrong -- it's amazing that it even works at all let alone that in practice it works so well.

And we don't even have a widely accepted body of knowledge, capital-P professional obligations, liability, etc. We constantly hire people with no formal training, give them no formal training, and make no expectations of their expertise. We hire them for lots of money and put them in front of important projects and we promote them up. It's almost unreal.

Talk to a civil engineer or a doctor about what it took them to enter their profession and the amount of work they have to put in to maintain their license. And they get paid less than most software engineers.

And yet it's still somewhat unbelievable. Digging tunnels requires a lot of expertise and domain knowledge but as others have mentioned: there are only so many rocks out there to encounter. Once you have a thorough survey there are scant few unexpected problems you might run into.

But computing? Well... unless there's a battle-tested library that solves the exact problem you have then you're basically solving the problem from scratch. And one mistake is all it takes. You can't just add an extra I-beam or use a stronger steel... there's no fudge-factor in discrete systems. The whole enterprise of computing is managing complexity -- we have whole fields dedicated to the study of complexity with plenty of unsolved problems!

I believe it is just the nature of the work and why it remains so infuriatingly difficult to predict outcomes.

My pet response when someone asks why estimating software is hard: you've lost your keys in your house. give me an estimate on how long you think it will take to find them. I know you're going to think that if the keys are in the usual place it will take less than a minute. But if they're not... If you check all the places you might've been in the last few hours, maybe 5 minutes. But if they're not there then you'll have to think about how to search your whole house which could take hours. And what if you still don't find them?

And on and on.

Nobody will die if your webpage doesn't render but software is used in safety critical environments too.

Safety critical environments though are just fundamentally different when software is developed. Like a reality of them is that the assumption is a development time of years if the needed platform doesn't exist, and if it does then the changes need to be trivial to the point of being done by the time you propose doing them since all your time will be spent analyzing and studying the impacts.

I meant those who make the project don't die in software

> since most likely the only person with a real understanding of exactly why something is difficult is the person doing the work.

This is often the case in other engineering projects as well.

But there's often less of an incentive to "confirm" that this is the case because if you (claim to) have hired the best people, to have given them the best possible training and working conditions, and every support in doing their job, it rarely makes any sense to go to them and figure out if they're really late because the problem is hard, or because they're just slacking off.

The investigation itself is rarely meaningful. Even if they are slacking off, what exactly do you expect they'll say? Yeah boss, we're just slacking off?

Managers who second-guess perfectly competent teams this way are usually shown the door (if they ever made it to managing something).

Exactly this

It also does not help at all that software "estimates" are typically just sticking a finger in the air and seeing how hard the wind is blowing at the moment. How many engineers are doing things like using real numbers from previous work to build models before estimating? Do we really think that every project is such a unique snowflake that we can't build models? You don't even need that much data, as long as you're understanding that less data means less certainty. Which is also why every estimate should be either a range, or a single number with a confidence. "Previous work shows we can handle a project of this size in 6 months 85% of the time."

Of course, this is not all on engineers either. I'm sure everyone has seen the project manager who takes estimates as commitments. Cultures that allow that to happen will see repressing of generally good estimates. (If you use modeling, you just boost your confidence interval appropriately. 6 months at 85% or 9 months at 95%? Pick which number you give based on your experience with the PM!)

In my experience, PM's or whoever usually want estimates on the spot. They want estimates fast, but then they treat them as though they were well researched. If you tell them "there's a 75% probability we can get it done in 2 months" they hear "we can get it done in 2 months".

There's also a tendency to leave out important information. I recently worked on a project where 1) more than half of the features were not in the requirements because the product manager assumed we could re-use existing functionality from a completely separate application (we couldn't); 2) half of the requirements from the new work were left out of requirements because they didn't bother to specify them; 3) a critical requirement regarding how data was to be aggregated in search results (which is the primary feature) was not included because the architect didn't bother to tell anybody about it except for a passing "hey, what if we did this instead" before going on vacation. This caused 2 weeks of re-work after we were done, that would have taken 2 days if we did it from the start.

Our engineering team reviews all requirements as a team before giving estimates and this STILL happened, because we couldn't know what was missing. Good estimates begin with good requirements, and usually the people responsible for those do not end up being accountable, it ALWAYS falls on engineering.

That serial approach (get good requirements; design and code; test) always works that way. An iterative approach can work better. Why isn't the architect in standup at least during the beginning of the project? All this could have been shortcut.

Because developers want to be left alone and also because they think meetings are unnecessary

The conversion of estimates into commitments isn't some exception to the rule, it is the rule which is why only fools give the business estimates for things.

Also ...

Do we really think that every project is such a unique snowflake that we can't build models?

Well, yes. That's inherent to what we do. Every project IS a special snowflake. If it wasn't we'd just download the software and install it. Oddly enough, installing and configuring software that is pre-made is very predictable and such projects rarely overrun. The sort of projects we're talking about are where pre-existing software won't do and thus, by definition, what you need is something special.

Exactly. It's hilarious to imagine management coming to a dev with a problem and a set of objectives and the dev replying mockingly "What are we some kind of special snowflake that we have to satisfy a different set of requirements than an off-the-shelf solution can satisfy?".

Every structure and bridge and road and tunnel project is obviously unique also. Unique terrain, unique architecture, unique engineering. If the idea is to look to other engineering to improve this, again, it's not like software is some kind of special.

They're only unique in trivial ways. Roads are made of the same material everywhere - they're different only in some strict geometric sense.

Meanwhile even very ambitious tunnelling projects like the Gotthard Base Tunnel, if you watch documentaries about them, they only hit a very small number of really unexpected issues even over long periods of time. Tunnelling is an incredibly predictable business. You buy some TBMs, set them going and worst case, you hit unexpected rock types or have an unexpected malfunction. The technology is advanced but rock is the same as rock has always been. Once the project planning is over requirements don't change. The course you're on doesn't change. Workers are largely trainable and replaceable - you never find you're unexpectedly relying on some random worker somewhere deep in the org chart who is 50x more skilled than their coworkers and who just got poached by a company that pays 3x as much as you can. The users/customers have no input: they get what you deliver and a tunnel is such a simple thing talking about whether they like it or not is a nonsensical question - it's a tunnel.

> They're only unique in trivial ways. Roads are made of the same material everywhere - they're different only in some strict geometric sense.

That's about as accurate as saying that software projects are only unique in trivial ways because there's probably already a free library or plugin that can do whatever else you need. It's easy to assume your occupation is much harder than everyone else's but we rarely have deep knowledge of the challenges other people face day to day outside of our own line of work.

As a simplified example, the design of a road, its pavement layers and its foundation is determined by factors like traffic loading characteristics, service requirements (peak capacity), speed limits and visibility, ground conditions, climate and more (see Caltrans' Highway Design Manual at http://www.dot.ca.gov/design/manuals/hdm.html), many of which rely on professionals in entirely other fields.

As kaspy points out in his, this is just more software engineering hubris playing out. I took architectural drafting classes in high school, and there are tons of technical differences and considerations that go into building design. And I was only dealing with drawing them, forget about having to have all that in my head and actually being able to make decisions on it.

To make what I hope is an apt analogy back to software, you are basically saying, "Oh, their job is easy. All they have to do is follow established design patterns!" But, of course, we also have design patterns... Why don't we say the same thing about ourselves? Because we know that that's complete bullshit; there's a lot of thought and wisdom that goes into actually building stuff around those patterns.

Yes, but architecture isn't the same thing as road building where the same small set of variables play out repeatedly over centuries. The work an architect does is much closer to the work software engineers do.

> How many engineers are doing things like using real numbers from previous work to build models before estimating?

Fogbugz created a feature called Evidence-based Scheduling (http://help.fogcreek.com/7676/evidence-based-scheduling-ebs). It's probably the only real quantitative approach that I have seen while working on web development projects. I'm probably wrong to assume that more "technical" fields like aerospace do much, much more than this, but it was really interesting to use this with what was mostly CRUD-work.

EDIT: added link.

> Previous work shows we can handle a project of this size in 6 months 85% of the time

More like: Previous work shoes that this project should take between one week and eighteen months at a 95% confidence interval.

...there aren't many projects one can do 300 times to narrow that window. And asking for a date instead of a confidence interval is asking for an ambiguous estimate in the first place.

Another tenet is that work is work. You attempt to break the work into chunks that are close enough to previous work efforts to use your model. If you can't do that, then you don't actually have any idea of what you're doing yet. Which is fine, but you certainly can't estimate in that state.

Is this how you/your team/your company work? Do you know of any resources you would recommend for those of us who are interested in learning more?

This is generally part of the "No Estimates" movement. I learned about it from an internal talk, but I will ask the speaker if he has any resources I can point you to.

We are not there yet, but are moving in that direction. We weren't previously even collecting the metrics required to create models in the first place, so we didn't have any data.

Yes, I get that all engineering (not just software) has inherent uncertainty in estimates. And there is always the chance for unanticipated events causing major overruns. But I still think that the uncertainty in software is significantly higher than in other engineering disciplines.

Of course I don't have any scientific evidence for this claim. But there are lots of phenomena that exist in the world that don't yet have scientific support. I think that software his higher uncertainty because it is much less constrained than physical engineering. There are a relatively limited number of ways that one part of a physical system can impact other parts, and those are constrained by the laws of physics. Software systems have no such laws. It's often possible for any component to write to arbitrary locations in memory controlled by any other component. This is kind of like a rusty hinge on a 34th floor bathroom door causing a problem with a doorbell on the third floor. Those kinds of actions at afar just don't happen in the physical world and if they do, they happen via pretty well understood physical mechanisms. To make matters worse, the discipline of software engineering is less than a hundred years old as opposed to thousands of years for physical engineering.

It's not about feeling special. I think there is something fundamentally different about software.

The only thing different about software is we haven't been doing it long so we don't know how to estimate. If you are writing a CRUD web app, it is just like the million others that have been written before and you should have the ability to give reasonable estimates. If you are writing a self driving car - that is new ground that only a few have attempted: there are many "unknown unknowns" that are hard to account for.

That's fine if you:

• Never upgrade your tech stack.

• Always use people of exactly the same level of skill.

• Assume the project stops at implementing a static set of requirements given up front.

• Assume the requirements are correct.

• Assume there's no political dimension to the actual deployment and usage of the app, i.e. the project is just software and not a business change project.

In practice none of these things are ever true. The business doesn't want a CRUD app, it wants an automated process that it probably can't explain, will change half way through the implementation and some of the employees may resist deployment of the software. And people expect software development to get cheaper and faster over time, as with everything else in life, so you can't exactly ship a Visual Basic 6 app in 2018 because that's what you happen to know best so you can easily estimate work with it.

I've been developing CRUD apps for my company's clients for eight years. They're all superficially the same, but every single one of them has had something unique about their schema design, and they all have different business rules (in a general sense and in specific details) that make every project unique. We have a model that gives us ballpark estimates before we get into detailed analysis, but every time a customer insists on taking our ballpark estimate and treating it as a fixed-price commitment, the project becomes uncomfortably stressful.

I was just talking to a dirt moving contractor, he would say essentially the same thing as you.

Estimate higher then.

If I am developing a standard project, I will give you accurate estimates that are often correct. If I am building a custom project, my estimates will vary greatly, based on how custom it is, how well you describe what you want, and how many times I can expect you to change your mind about something.

It's really easy to tell whether you're building something standard. If it is standard, you don't need to write software for it. Say you want a standard blog. You use Wordpress. Say you want a blog that's kind of like Wordpress but a little bit different. You need to hire a programmer to write a custom component.

Effectively, all the software we write is custom. Once something becomes standardized, you no longer "build" that software. If it is standard, you install and configure it.

This is the same in the real world. If you need a standard kitchen, you can estimate how long it will take you to go IKEA, buy the cabinets, bring them home, and install it. If you want something custom, it all depends on how custom. If you want cabinets that retreat into the wall, have glass fronts, bulletproof countertops, can adjust in height so that both your 5'2" wife and her 6'11" husband can use them, in the mobile trailer that needs to tolerate temps from a dry -40F up to humid 100F without discoloration and warping, good luck. Oh, and they need to look really nice and be easy to clean. Estimate that!

TL;DR: when hiring a programmer to develop a project, nobody wants standard IKEA.

My point about software systems being less constrained than physical systems means that even ho-hum CRUD apps will likely have more unknown unknowns than a ho-hum dirt moving project. Also, the task of stating the requirements for a software system is much more involved than stating the requirements for a bridge or tunnel.

In short, I think there are very clear and tangible things that give software estimates a meaningfully higher uncertainty than other engineering disciplines.

Software engineers seem to be prone to this sort of thinking in general. I know I was at first. I think it's common to just not be especially familiar with the practice of science, with other types of engineering, to not have exposure to other industries and thus have no other frame of reference, and to just be young and inexperienced. It's very easy to look around at your own experience and think "this is so complex and requires immense amounts of thought and coordination" and to somehow think that's unique to your situation.

Software is the only discipline that exclusively creates practical results via ideas.

In excavation, you can see the dirt and rocks, and say "This terrain is different than we expected." and someone else can see the same terrain and say, "You are correct. Our assumptions were wrong."

In software, you can't show anyone that the situation is different than your assumptions, because the assumptions themselves are the material that you're working with. Building software is the process of turning assumptions into results.

>>Software is the only discipline that exclusively creates practical results via ideas.

You're going a bit far there. How about writing, design, art, etc...? There are plenty of creative industries out there.

Thats the point, software is a creative endeavor with more in common with those fields. Does anyone wonder why the novelist or the artist is taking too long. Why do they get that freedom but not in software?

Probably because, by and large, they work for themselves and not as often in teams.

Writing, design, art, and other creative disciplines generate products. They do not create results, by which I mean, software itself generates results. You can write a book, but the book doesn't do anything. A person can read it, but the book doesn't generate results.

In those examples, a rush job is qualitatively worse, not something completely useless. Half finished tunnels, bridges, and (usually) programs provide basically no value.

A key difference is that people have been sailing for thousands of years and tunneling for hundreds. We've been developing software for decades now and are learning how to do it much more quickly than we're learning new ways of sailing or tunneling. In that regard, it's a creative process and more akin to writing a book than the examples you mention. Sure, risk assessment and management are all well and good - when they're practiced, but when it comes to doing something new (i.e. not writing a simple CRUD app in the software world), seeing it as a mechanical process is what leads to these tensions.

This capture my view as well. In the past decade few of the projects I worked on were mechanical. New languages/frameworks lead to new classes of problems and much of the overtime is troubleshooting and working around those. Some time is saved by experience but not as much as I'd like.

I had a similar reaction.

> It’s not because we’re narcissists who need special labels. It’s because people keep running into difficulty trying to square the very definition of a project (something with “defined scope, schedule and resources”) with our real world experiences.

Unless someone has an example of a project that can be easily scheduled and scoped, I am going to go with us being narcissists.

Whether it is writing a screenplay, interior designing the living room, designing an aircraft, or building bridge, scope and schedule are always tricky. No software required.

When something has a fixed scope and can be dependably completed in a fixed amount of time, the appropriate English word is “task.”

You can combine these effects by having a construction effort that's also heavily dependent on software - see Berlin Airport for an example.

The unique problems with software I think are:

a) some things are genuinely novel: how long will it take to make a self-driving car? Nobody really knows.

b) big business projects may have incoherent or incompatible requirements, but the interactions between these appear late in development and the effort to clear them up is huge and fundamentally sociological - it has to feed back into changing the business process.

A non-tech acquaintance of mine was struggling to start a cannabis business a few years ago. When he found out how much non cannabis-specific stuff went in to starting a cannabis business he lamented that he could be a successful as Bill Gates was if he only had to worry about one thing (writing software) the way Bill had.

You think software developers are unique in making claims that their field is unique in some regard?

A lot of us have the issue of perspective. We believe we have problems no one else has and fail to consider that others may have problems we can't perceive. Out of sight, out of mind.

Also, millennia is already a plural.

The thing is in projects that you use as examples it's much easier to explain what is going on as people have pretty sane frame of reference even if they are not domain experts.

> Maybe try digging a tunnel through a mountain, where the kind of rocks and caveats you find on the way can make you overrun your estimates?

Usually the client doesn't call halfway through the project and tells you that the tunnel you're digging really needs to start 10 miles further up the valley...

Stuff like that happens also in construction. For instance the BER airport: Midway through the project they decided to build two instead of one floor.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact