Software development requires servant leaders
adl.io
adl.io
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.
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
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.
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.
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.
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.
I heard this on the radio once. You have to be prepared to be walked on when you're the one keeping the peace.
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.
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.
Sometimes you should build a raft instead of trying to pretend you can build major infrastructure in no time flat.
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.
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.
Far too many confuse the two, and the discipline and flexibility needed for both.
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.
It does not always pay to specialize.
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".
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.
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?
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.
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.
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.
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.
Technical and programming skills have very little overlap with successful team management skills. It's the very essence of the Peter Principle.
Hell, the only reason I know what servant leadership IS is because I took a business degree about 10 years into my software career.
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.
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.
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.
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.
Sorry about hurting your agile feelings!
The lack of natural structure in the work means communication and collaboration among the development team(s) is all that more important.
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.
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.
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.
http://www.ejinsight.com/20180406-hk-engineers-raise-concern...
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 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.
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.
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.
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.
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.
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.
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.
(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.)
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 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.
With deceit, propaganda and manipulation tactics?
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.
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").
The language obviously implied the emperor was just the first among equals, although more a political framing than actual attitude held by emperors.
"...let the greatest among you become as the youngest, and the leader as one who serves."
Luke 22:26
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).
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.
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.
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.
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...
> 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.
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.
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?
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 :)
People are too concerned with perfect software.
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.
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.
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".
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.
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.
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.
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.
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.
No software project I've ever worked on let me put my name on it.
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.
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?
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.”)
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.
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.
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.
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.
Whoa, let's not get carried away here.
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.
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
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.
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”
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.
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."
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.
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!)
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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?
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.
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.
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.
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).
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.
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.
• 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.
In short, I think there are very clear and tangible things that give software estimates a meaningfully higher uncertainty than other engineering disciplines.
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.
You're going a bit far there. How about writing, design, art, etc...? There are plenty of creative industries out there.
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...
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 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.
> 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.”