I’ve been pondering this a lot lately, as an engineering leader.
Masters in my organization have an extremely high ratio of value shipped to hours worked.
This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such that the cost of adding more value to the system remains constant as the system grows in complexity.
I don't disagree with this, but sadly, a prerequisite for that is a position of privilege where you're able to push back against non-valuable work. I've seen many, many very good software developers that have this quality, but get overruled, and their true value goes unrealized as a result.
Part of what it means to be a senior engineer is that you have a mastery over the soft skills/people skills commensurate with your engineering abilities. Someone who knows how a bridge should be architected but cannot navigate the politics of city council necessary to get it built isn't much of a bridge builder.
The importance of good politics cannot be understated. Politics in this case is roughly defined as getting people onboard with your plans.
While your bridge analogy is true, I feel it's even more valuable to have an informed view for what's on the other end of that bridge. If you work the politics and use all the right materials to build an efficient bridge that's great. But a wonderful bridge to nowhere is still a bridge to nowhere.
I say this because as a finance guy, I've been on lots of projects that look great on a spreadsheet and marketing, sales, or somebody else is really pushing for the investment. That's the point where a technical person takes over and builds what's asked, or a really great technical person may ask a few questions and raise a few points nobody else considered and the whole bubble bursts as we realize it's not feasible/or we can test it in a certain way before investing big time/money into it.
Probably not mastery of SE as OP asked. But mastery as a business partner within an organization.
That sounds amazing, sadly in a lot of organisations that isn't how it pans out.
Either the engagement with technology doesn't happen early enough, or when it does, the technology point of view isn't given the weight it deserves. The ideas have already caught and too many people are invested and have 'faith' it will all work out.
The crux of this is that many of those people who carry the weight in decision making don't actually carry any risk or responsibility for delivery. Given the scale of engineering and time to deliver, by the time it comes to fruition they've moved on, so they never experience accountability for ignoring the advice.
For instance, in my experience at a FAANG, the issue was often that a new technical solution was proposed, architected and built before any business/market people got involved with the result that loads of amazing, brilliantly architected and completely useless projects got built.
(My favourite time was when a (really smart, to be fair) software engineer rediscovered the normal distribution while looking for a way to reduce storage requirements for an analytics product).
If you have a load of smart engineers, sometimes it can be a more successful strategy to just build something than to pay EY £250k to do market analysis, get a load of execs bought in who then will "make it work" even if it shouldn't, or kill it off even if they shouldn't, and then finally get a committee-written spec handed over to be built in a rush.
Sure, there are pathologies at both ends of the spectrum. I do think it's worthwhile (particularly here), that software engineers/technical people are subject to their own set of development pathologies.
True. I’ve witness all of these things as well. I’m not implying that organizational decision making is perfect if only it had better technical people providing inputs by any means.
Again as a finance guy, this is a major skill I have attempted to develop for myself/team. When projects spin up, I’m typically at forefront and involved in every project technical or not (controlling the purse strings). Many finance guys are know it all’s TBH. They build their ROI models, etc. and making dozens of assumptions it’s then treated as gospel. For some reason, it’s valid to ask “why is this project underperforming our expectations” but it’s often taboo to ask “did our expectations even make sense”. I try to change that where it exists too.
All to say, people like me find people at the onset of the project to gather inputs. If I know you as well versed with track record of valuable insights, I’m more likely to reach out early. If I have worked with you at this stage and you your input is just one of “we need specs/tell us what to build and we can build it” you’ve not added any value to the conversation and I’m likely to not include you next time because I know I just need to bring you specs once project is approved and that’s a different conversation for another day.
This is why I say “business partner”. Being able to understand your company, the politics within, how decisions are made, where you can inject value along the way. These are all traits of people with fast career growth in slower growing firms. You transform from Programmer #13 to people knowing and respecting your name. This is important in talent reviews, etc.
Good one. Another on the same lines, and also related to your parent comment's point about politics, is:
Getting the users in the org to, you know, actually use that well-specced, well-built project, which was delivered within time and budget (or with only a small overrun). I mean, use it at all, or use it enough for it to deliver its benefits. Real life issue. Seen it on at least a few projects I've worked on, including two early in my career. Inertia, luddite fears, turf wars can be some of the causes.
The most difficult hurdle is that there's never that direct communication between the finance guy and the tech guy. Projects tend to get lost in translation, where you have multiple layers of departments and emails and roles playing telephone. If an organization can have that direct finance-to-tech guy/gal link, it would be the most effective way to provide the most effective value imo.
It’s definitely a problem worth focus. I recommend networking with some of the finance folks. It’s as simple as a lunch meeting, ask them about some of the projects that are in planning phase, offer your assistance. You’ll have to figure out what is the post-COVID equivalent.
I find some in finance and IT get along fairly well and can build a bigger rapport fairly easy. We’re all excel nerds and many of us have taught ourselves how to program to an extent (VBA, etc).
Depending on the organization, we tend to be more focused on leadership support. A junior analyst will get much more face time with VP and up than down. So that’s part of the problem is those connections just don’t always exist. When they do, it might be with an IT director which has maybe become too far removed from codebase or implementation challenges. It happens with every department within the organization, not just IT. My experience is outside the software industry so may work a little different if sole function of the company is software.
In your analogy if I get really good at getting stuff passed through city council, what would I optimize for ?
A: Building better bridges ?
Or B: building better money making bridges (potentially of of inferior quality) ?
I'd bet there are more takers for B. And at that point we now have better city council optimizers than better bridge builders.
Lets say we now make a team of some folks from both groups. Now who's going to able to get more people onboard their plans? Its the city council optimizers again. And now some bridge builders figure it out and become better optimizers than builders.
We then take it a step further and add competing teams. Same thing repeats. The team better at city council optimizing beat the better builders all the time.
In this whole process its the quality of the bridges that stays the same ( in most cases it goes down) and the costs of it keep going up.
My sad, unfortunate observations in the field.
Love to see a way out.
Edit: in this way of thinking , the assumption is that there are higher chances of making more money from poorer quality bridge than a more advanced, higher quality bridge. One exception to that is the strategy where you first provide better bridges at lower cost and then bump up the prices for maintenance.
Unfortunately this assumes that the politics of the city council is somewhat outcomes focused. If the mayor is intent on awarding the contract to her uncle no amount of 'soft skills' will help (and attempts to apply them may be counter-productive).
It's usually helpful to have an internal locus of control, and look for things in oneself (here, soft skills) that can be changed. However, sometimes reality just doesn't afford opportunities in a given situation. Accepting where that is that case means being able to extract oneself from a situation rather than wasting time on it.
This happens to me at my organization fairly often. I build solutions I'm asked to build and then an abusive architect coopts that work and rewrites it in a shitty, unusable way. Users cry at me, but when I tell them what happened, they are silent. No one cares enough to cry to leadership. And the leadership have clearly said they have no intention of overruling what said architect talks about.
Leadership puts an architect in place because they don't have the time to care about code level details. I would personally mention it to leadership but frame it in a way that your work is being rejected but nobody is explaining to you why so that you can learn and do better next time.
Unfortunately in a large software engineering organization tact and political savvy is more important than raw engineering skill. Once you've been in the industry long enough, you'll understand it.
One of the problems that's common in organizations is that most of the work at the junior level is highly focused on individual contribution and that completely flips at some point in your career.
There's another facet to this which I think is far more important that OP question of "What [exactly] does mastery 'look like'?".
The more important question is "how do you cultivate mastery?" How does your organization get to a place where people can develop mastery instead of the organization trying to create it instantly by hiring "the right people"? Regardless of what people may claim, hiring is not a solved problem. It's _really_ hard to identify candidates that are true masters at what they do (let alone getting them to quit their job and join your team).
By the same token, it's also _really_ hard for true masters to find a place that understands their value and, more importantly, will allow them to do their thing and provide career satisfaction. A lot of talented people are locked out of jobs because someone thought their career trajectory wasn't quite right/impressive.
Training and mentorship, however, are better understood and have lower stakes. It makes me think of Bell Labs. I know a couple folks who worked there who had very "unimpressive" backgrounds, they started as techs but rubbed elbows with stellar talent in a place that cultivated discovery and collaboration. Over time while there and in other places they were able to rise to principal design engineers, beyond what many who went to elite universities achieve. They credit their formative years in Bell labs with getting them started on their career path.
The thing is, Bell Labs didn't have an epically selective hiring process, nor was the compensation insanely high. They provided an environment that _attracted_ people with mastery and those who were passionate about what they do, they developed talent within their walls rather than trying to merely buy it or find it.
This was for electrical engineers, but the same ideas can apply to software engineers.
That's a tough one. Often the sensibility about what needs to be done comes from hours/weeks/month/years hacking away at their codebase in their specific setting. Much of that has to be rebuilt from scratch in a new place. If you don't find that same connection with your work at the new place - or are unable to develop the relationships with your peers or your manager, you may not end up able to make that impact at the new place either.
I tend to encourage folks who come to me about quitting to explore opportunities within the team/organization/company before leaving so they can leverage all the social capital they've built up.
Absolutely, especially in bigger organisations where one part may be completely different in terms of how is organized and how is operating from another one.
I worked at one place that was a basket case and finally started to push back. The HR person seemed shocked that I was concerned with the business value of a project, but i had people telling me i wasnt worth what i was being paid -- I could show the next assignment had $0 in business value so if i spent more than 0 hours on it I'd just be digging myself a hole.
If you think something does not produce value and you have knowledge to back it up (you could think something is of no value if you don't know the big picture), and you are "forced" to do it anyway, then it all depends on pay. If you get a lot of money for this, you can exchange these later to fill any gaps that this will create or simply leave the co, unless you want to be known for doing fool's errands and stroking managers egos.
> They are able to discern and avoid work that does not provide value (this is often their greatest skill)
junior dev here...could elaborate a little on what this means? Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
I can give you an example from my career. We were building out a new webapp feature to deliver medical textbooks, which we had as xml documents direct from the publisher. Our customers, mostly large academic libraries and medical research companies, would get the electronic access to the books for much less than it would cost to get sufficient physical copies, and our cost for supplying the books would be minimal.
A problem came up. Many of the libraries were government funded, and required physical possession of any books they purchased. I was in a meeting with the c-level execs, sales directors, and pms, and they were planning out the cost of building an organization that would produce a cd-rom version of the textbook products. They were going to need a large team to manage creating the books on cd, and for managing the production and mailing of the CDs when orders were received. It was going to cost a fortune.
I told them to hang on a minute: I'm already converting the xml for these books into html for display in the app. I can easily generate static html too, write it to disk, and generate an iso file, every time we publish a new book. Then I can add a download link in the webapp, and if they need a physical copy they can download and burn it to disk themselves. We'll include instructions. This will take me maybe an extra week, and we'll have no ongoing operational costs.
I think I got a $50 Amazon gift card for that suggestion. Or maybe a Starbucks card.
You have to be present in the meeting. All the places I have worked - and I have worked in many over 15 years - do not allow this. You need to be in a startup to be close enough to have this kind of impact. Agile just makes this situation worse. It's incredibly frustrating to be see the value you can add, but having no ability to make it happen.
Can't have pesky engineers with their pedestrian technical concerns mess with the business decision makers' thought process. A good engineer takes whatever the creative, smart visionary comes up with and implements it down to the smallest detail.
It seems like this value you brought in is "outside" the domain of software engineering, however. Yes, the solution ended up being found in software engineering, but the problem came from a business operation thing, no?
(I wish you had gotten more thoroughly compensated for saving them a fortune.)
If your only skill is being able to write code, your skillset is relatively weak.
We are called Software Engineers, but what we really are is people who solve problems with code.
The important part is solving the problem. The fact we do it through the medium of code isn't that noteworthy.
If solving the problem requires knowledge from outside the domain of programming (Spoiler: it almost always does), then you learn what you need to from the relevant domain.
Software engineering requires understanding enough of the reason behind requirements to know when the requirements could be simplified or should be augmented. I would even argue that understanding business needs and translating them into practice is the fundamental role of software engineering.
This requirement might never have reached a software engineer in many organizations, and perhaps that's what I mean. So part of the mastery is ensuring you are around to provide solutions when business needs are being deliberated. That's fair.
An engineer's job is to solve a problem creatively, not execute a rote technical procedure. The people who are just fed detailed instructions to execute are called "technicians" in the traditional industries. If you want to claim the title of an engineer, act like one. If all you can do is write code to spec, you are a technician.
Your use of "spec" here is a weasel word to make your point. There are many kinds of specs. The spec here is "users need a physical copy", the organization was intending to solve it by using the services of another business and a bunch of other expensive and complicated stuff that I was considering as categorically different from software.
Business is not outside the domain of software engineering. "building the right thing" is more important in engineering than "building the thing correctly". If the proposed solution or problem to be solved misses the mark, most of the potential value has been lost, and excellent execution will not be able to recoup that.
Thank you for the story, I definitely understand now. I am also relieved that you were compensated for this critically important pivot! /s
I am hoping this will be an area I can eventually excel in. I was a senior PM for a while and decided I wanted to write code instead. Been going down this crazy career change for about 6 months now. Right now I am just trying to survive and learn the basics of software development.
When I was PM I certainly had the luxury of working with invaluable devs I could brainstorm with on ways to optimize a feature idea that maintained customer value in the shortest time possible. I need to learn how to become that invaluable dev I had.
I hope you are joking: “I, a paid employee, have a wonderful solution to our problem that will save the company a lot of money, but I won’t tell you if you don’t pay me even more.” I think the answer to that would be something like “hmm, if you aren’t willing to do your job for the salary we already pay you, I don’t think there’s any reason to pay you at all.”
This is the biggest difference between a Junior Engineer and a Senior (or Staff Engineer).
A Senior Engineer knows what the highest-value work is and is influencing/driving the roadmap. A Senior Engineer says 'no' more often than 'yes' and backs it up with a 'why.'
Most Seniors are driving the roadmap simply by virtue of being a Senior, and most Juniors have no opportunity to influence the roadmap because Seniors control the decisions.
Of course ideally everyone can contribute, but I think that's relatively rare.
If the structure of a work place is very strict, then yes this is 100% true.
I how ever could already experience a more open scrum process in which we all have a say.
For me it all started in an university project with four (incl me) people.
I denied a good portion of the requests my supervisor gave me there, not because they were bad, but because they simply did not fit into the time budget or were not realistic.
She was actually very happy about that because she was not that tech savy back then and learned a lot threw the process.
Very good experience for me and we finished the project on time and exceeded expectations.
> Generally speaking the PM is the one creating a roadmap and informing what is the highest value item to work on. I must be misunderstanding what you're referring too.
Experience flips this equation around. The PM is creating the roadmap based on my input and expertise to decide what will be the most valuable use of resources. You move from construction worker to architect.
It's very easy to get distracted as a developer on something that adds little to no value. You will do this repeatedly throughout your career. Try not to :)
It may also depend how much you're micromanaged vs. picking your own path. Sounds like you're saying none of your work is self directed, and you don't participate in design decisions yet?
Anyway, even if you don't have much say there's still ways to direct your work. You can push back against whatever is demanding the low value work.
There are some teams that only work on high impact projects. If you feel that your current team is only doing work that's not valuable, you need to change teams or at least let your manager know to change your project. Ask for projects that you think will bring revenue to the company. Revenue = impact or increase in productivity of other engineers (this may involve writing an internal tool, etc.)
It reminds me of a guy I used to work with. He two-finger typed looking at his keyboard all the time, but the code he did end up writing was exactly what was needed. Consistency and quality was much more important than cold, hard "productivity".
Absolutely. Touch typing is a game changer, not only because with practice, you can just think the code and see it appear on screen, but because you no longer have to glance at the keyboard and your full attention is on the code.
If I'm creating something from scratch or refactoring then a keyboard definitely gets in the way. Of course when I'm writing something from scratch I usually iterate a few times before I have code that I'm satisfied with, so going through those iterations requires a lot of moving things around.
If I'm solving a hard problem (i.e. architecting a system or coming up with an algorithm) then 99% of my time is spent thinking rather than typing.
Not writing from scratch, and not what I consider "nice" code (specifically avoiding the term "good" here). There are plenty of cases that wind up being typing jobs essentially. Usually, that means you're not really designing code as you write, though.
Depending on what I'm working on, just dumping stuff to an IDE buffer at 70WPM can be 10% or more of the time something takes. Which is enough that typing slower would have a noticeable impact.
Enabling the org to accomplish more with less (or keep it from falling into different pitfalls) is sexy.
I feel it's a core part of my job to keep the rest of the eng team happy and producing value. A lot of times this comes down to seeing problems as they arise (ideally before them, but it gets harder to convince management of future issues if they haven't manifested yet).
> the best ones can direct a whole team away from large swaths of work that is not valuable
Can't overstate how valuable this is. A team which can expose its members to this kind of leadership by example and direct collaboration will grow and outproduce teams which don't by an order of magnitude.
One has to be very careful in determining what work amounts to "value shipped". It's not uncommon to have a few persons who seem to ship all the value, while the rest.. just enable them to do so, by doing the required, but invisible stuff, like the refactoring required for the new feature to ship, or fixing the bugs that makes the customers not leave, or attend those meetings that has to be attended by someone. This is somewhat related to the 10x engineer story, sure, some are a lot better than others, but sometimes it's not entirely undue to their situation. Maybe it is a skill too, to be aggressive enough to grab the work that looks most valuable and push that through, leaving your team to do the rest.
(just unpacking) Prediction of value, initially and over time, requires market analysis.
Given that, predicting which projects will produce that value, and which designs will accommodate future additions of value, is engineering.
I still like Parnas's On the Criteria to Be Used in Decomposing Systems into Modules, where the choice of "information hiding" requires predicting what is likely to change - and predicting value.
They're totally different words. I used to be an engineering manager with direct reports who wasn't really much a leader. Today I'm an engineering leader without any direct reports.
Leadership happens from the front and doesn't really have anything at all to do with year end reports and making sure everyone shows up on time. Management rarely does more than HR busywork. The way many engineering mangers work they often have skills so outdated as to be effectively non-technical.
Leadership can happen at all levels regardless of title. Leaders often are some of the most skilled technicians, able to have an outsized impact on both the team and the direction.
I think that's an artificial split. Management is not only about HR busywork, it should also include all the things you've mentioned in the leader category.
Is it an official title? I keep seeing it everywhere now, everyone is a "leader." What exactly does it mean? Do you proclaim yourself a leader, is there some vote on it?
From my perspective it's completely meaningless and usually ego stroking.
Imagine an evaluation system based on this principle. It would be simple cost minus benefit, without regard to technical merit or project milestones or other silly process-based evaluation. This is the opposite of most companies. Generally promotions have to do with the size/cost of an employee’s piece of a project, not the benefit. Managers would be fighting to reduce their team sizes. I don’t know how you would back-propagate value though.
Masters in my organization have an extremely high ratio of value shipped to hours worked.
This means two things. They are able to discern and avoid work that does not provide value (this is often their greatest skill), and the best ones can direct a whole team away from large swaths of work that is not valuable. And they are able to build systems such that the cost of adding more value to the system remains constant as the system grows in complexity.