... by Phil Koopman at Carnegie-Mellon:  https://betterembsw.blogspot.com/2021/05/job-and-career-advice.html

I have some thoughts on teams. I have worked in the defense/aerospace industry for 40 years. I am an embedded software & hardware engineer. The facility I work at is an important part of military R&D.

My experience with teams is varied. My day-to-day works involves specialized hardware and software to support the warfighter. My current team is two people. Together we create a detailed specification for the hardware and software. I do the software development and my partner does hardware and FPGA development. I think we are very good at our jobs.

We don't go to many meetings, but talk and exchange email regularly to fine-tune requirements, discuss problems, etc. As a result, we spend almost 100% of our time on the current project.

My experience with large teams is not so good. Large teams spend entirely too much time in meetings. What's worse, most of the meetings have no agenda, so much of the time is wasted on off-topic things. Often there is no detailed specification for the project.

Software is written with no comments and no informational header. As a result, it's difficult or impossible to know who wrote the software, what toolchain they used, and the required external libraries, etc.

Another big problem is a lack of prototyping. As a result, hardware is usually purchased without knowing if it's appropriate or even capable of solving the problem. Issues usually end up being hacked in the software and the desired performance is degraded. Sometimes, the hardware just doesn't work in the expected way and has to be replaced with something else.

In summary, small teams made up of skilled people are usually much more effective than "all hands on deck" teams. They often produce a better product in less time. Good management minimizes the number of meetings and practices management by walking around.

What I've noticed in 3 companies and 6 teams is that the people always made the biggest difference in how happy I was. The 2 best teams I was on were full of highly engaged and focused professionals, the worst teams I've been on were full of unengaged folks happy with the status quo and doing the barest minimum. One of those awesome teams worked on remarkably boring things from a tech point of view. So, I'd say look around, find the people and worry less about the tech assuming money works out (odds are the money will work out anyway).

As to the prestige thing, I wouldn't personally value it. The best engineers I've worked with came from odd backgrounds and non-prestigious companies whereas the prestigious companies produced mediocre or worse engineers as a rule of thumb. Again, follow the people, they make a bigger difference than the tech or prestige.

Job security is a weird one, I'd probably say you're never as secure as you'd like to think. Myself and other folks I know had secure jobs we got laid off from or bullied out of. At 26, you're presumably in a better position to take risks too. This is another place where people trump other considerations too, folks that value your input and drive will work hard to keep you around. People win again.

So, I guess that's where I sit. If you don't like your team and you've got options, ditch the team. Odds are you'll be happier, make the same money or more and get new colleagues that help you grow.

I am an employee of a telecom provider in Alaska. We are a predominant provider across the state and have been for the past 40 years. I am roughly 7 years into my career, with 3 being at my current company. Dysfunction, miscommunication, and company politics in this organization are a given. Different groups can't communicate well together and we go through a company reorganization an average of once per year since 2018. I have learned that in this company the leadership mantra of "If you run out of ideas, reorg!" is strong.

I have been a part of groups that lack good communication, and have moved to a group that excels in that manner. The common denominator in all these situations is the manager. If the manager is a poor communicator, all members of the team will have a difficult time. However, I have a default mentality of collaboration and will do everything I can to work with anybody, no matter how difficult they are. This really does put you above the rest of the team, and good managers or leaders will see this. It is often the difference between a lackluster or poor performing employee compared to a top performer. Collaboration, communication, and teamwork are a must-have to be successful in engineering.

My advice is to learn everything you can about developing these skills. Think of it as an investment in your future training and employability, either at this company or any other. The ability to speak to managers, lead from within a team, and be a good communicator will put you above everyone of your peers. Then when the time comes where you have the opportunity to work for a manager or leader who is organized and an excellent communicator, they will quickly see your worth. My current manager saw this in myself and pushed for a 25% pay increase after 6-months on his team. I'd been paid below market value from the date I was hired, but this manager spent some political capital to match the pay structure he felt I was worth. These days a 25% pay bump is unheard-of, but by sticking with it, showing my worth, and developing my skills I was spotted by a great manager and it was worth it to stick with it and deal with the frustrating people.

TL;DR - Think of communication and collaboration skills as a training opportunity for yourself. You can learn to be a leader from within the team. Dysfunction has a cost, and I'm sure there are other members of the team who feel the same frustration you do. It takes time to build relationships, but take some time on your own or during some work hours to read about leadership. There are MANY books out there on this subject, but one of my favorite authors is Simon Sinek. Leaders are not always managers, and not all managers are leaders. By developing the leadership and collaborative mindset/skillset you can be a key part of the team and create a functional environment from within, but be patient. It takes time. And when a good manager comes along, you will be seen as a top performer who can help a team of individual contributors become a well-oiled software dev team.

Having worked at six companies of very different products, cultures and team composition, I have a few suggestions to the young engineer who asked the question regarding dysfunctional teams.

It is hard to over-emphasize the importance of a good tech lead – the expertise in design and implementation details, the focus on delivery, and most importantly, the willingness to share wisdom with less experienced teammates and to involve them in discussions at all levels. My fellow engineer was reluctant to leave the Prestigious company because of "location, projects, and career advancement opportunities". In my observation, poor execution can turn any interesting project into a nightmare, and a dysfunctional team can diminish any prospect of career growth. What's left now is the location. In the mid-20s, presumably without the burden of a house, the best location is where a good career can be found. My suggestion is to join a good team for a couple of years, build up skills in software engineering and a vision in product development, then come back to the current field where he feels passionate about, and be a tech lead and a mentor for the young engineers who will be in a similar position as he is in now. That, I believe, will be a very fulfilling experience.

The company that I was with that got bought out by a major defense contractor was run into the ground by bean-counters chasing commercial real estate, but they taught me one thing:  Everybody at a publicly traded company is employed to increase shareholder value - from the CEO to the custodian.  The higher up in management, the more that drives decisions.  

Look at your activities and priorities through that lens.  Whining does nothing but point out problems and it probably isn't actionable.  On the other hand, documenting the interfaces to your work products so that others can better utilize them or re-use them will bring the team's performance up.  Better yet, if your work gets re-used, the value of the investment in your pay just doubled.  If some important information is fuzzy and you are guessing, capture your guess in a shared document with your name on it, have it reviewed for a consensus (right or wrong), and fix it as necessary so you now have a Source of Truth.  

Unless management is an idiot, they will recognize a trend and your stature among the quarreling newbies will rise.  One of the most satisfying things is to tell someone "RTFM, and come back if you have any questions"

Regarding Dysfunctional teams. If the software group is as you say, then I would think your assessment that the "managers are good" is wrong. They should be able to recognize and rectify the situation. My advice, GET OUT. Not necessarily out of the company. I've heard it said, don't look for a good job, look for a good company. Once inside you'll gain insight, and there will be opportunities to move within the organization. Seeing you are already in, and assuming the company is large enough to offer other opportunities, look around. If that does not yield fruit then look outward.

Read with interest the anonymous piece on dysfunctional teams, it has some resonance for me. I've worked for the same SME (electrical switchgear and drives OEM) for 38 years since graduating. For a few years in the late 90s to mid-2000s, there were two of us working 'together' designing and developing 8/16bit embedded controller boards (8051, 80C167). From the off, I have always tried to be as thorough as possible (proof of concept, specifications, design, coding, commenting, testing, archiving) but not the fastest. 

My colleague, however, seemed obsessed with doing everything as quickly as possible, often without regard for the end result. His approach was 'get it out, get it gone'.  He raced ahead with hardware and software design, sometimes cutting corners to finish jobs, but when they hit test and the test engineers found bugs, the response was 'it's designed, it's done'. Test engineers discovered text hanging off the ends of lines on the LCD, unexpected behaviour when entering parameters and other anomalies, but he usually wasn't interested in fixing the bugs, or would only do it under duress. He also repeatedly refused to work overtime to fix problems, even when the rest of us were in at weekends and evenings supporting production, doing site visits, or fire fighting.

Where are the managers during the team meetings where time is wasted?  Your managers may be nice people, but they are not managing the project.  How about the stakeholder (the person who wants the project completed)?  Are they attending these meetings?  Do they see the lack of direction and focus?  If they are not attending the meetings, I encourage you to invite them.  Do it by saying something like 'we could use some direction in these development meetings'.  This is step 1.  It's low hanging fruit that might get things back on track.  The other thing you can do is take the lead by organizing/architecting things on an EASY TO READ flowchart.  Caps for emphasis.  Be open to making changes but if you outline things well and use that as a roadmap, it can cut down on time wasting meetings.  

Step 2.  If the managers are attending the meetings (regularly), I encourage you to look for new opportunities elsewhere.  You are not senior personnel or management so it really shouldn't be on your back to fix a team.  If you have to work long hours to learn new things to get a project completed, that is occasionally acceptable.  Working long hours to pick up the slack means you earn less and less per hour while the company earns more.  Avoid that.  There are many opportunities out there with good prospects and there are many beautiful places to live, wherever you are.  Any large city will have at least a dozen employers.  

Instead of advice, I will describe what I did in my case (I think you should decide by yourself on yours)/

My case was identical to yours. I worked 7 years in an embedded team. Job was good and challenging, also paid extremely well compared to other jobs in the area. I tagged along the best in the team and learned a lot. I also spotted those who were there just doing the bare minimum, barely pushing things forward.
2 years before I left, the leader and all the good software engineers left the company for greener grass. In those 2 years, I was the 'senior' developer in the team.

At the time, the thought of being the 'senior' just felt wrong. Not only that but, seeing other devs doing the bare minimum while you give all you got, just to be rewarded in the same way, it's really demotivating.

That and since management could not care less for hiring good/experienced software engineers, I decided to look for other jobs. Staying there would not have made me grow like I did. 4 years since I left, no regrets.

I'm very thankful for that job, but staying in it without good teammates to share/build things was just a no go for me as a junior engineer.

I have a comment on the subject of "Dysfunctional Teams":

Chances are there are others on the team that feel the same frustrations but do not know how to express it or have decided not to push against the current.

My tip for the young engineer is to step up and lead. Do not wait for someone else to come along. You can influence your team from any role. 

A book/author that would have served me well in my early career is Extreme Ownership by Jocko Willink.

Responding to “But the location, projects, and career advancement opportunities are hard to beat.”
Dude, you're golden, stay the course!

The piece about the young engineer in a dysfunctional team struck a chord, and I guess most of us have been there at some point. I would offer the following advice to the young man or woman. 

Especially when you are in the early phase of your career, don't be too scared to search for something better. These situations happen way more often than they should. Working culture is a bit like the atmosphere in a bar - the attitude of the people who run the place permeates everywhere. Software engineering is still a relatively young art/science (compared to other branches) and poor working practices are still all too common. As you become more experienced, this gets a bit easier to handle, as you have more chance of gaining enough influence to effect some positive change, but if you are in the first decade of your career, that is unlikely. Moreover, it is pretty important, in your early years, to try to get yourself amongst people who really know what they are doing and who care about doing a good job. The mentorship you can receive in a good team is truly priceless.

So my advice is : look around. Actively seek a team that looks like it has a positive culture. Go to interviews with the objective of sussing this out. It is not always found at places with the most prestigious reputation - you can also find it in small to medium organisations. But anyway, this is what you need. Team culture has the biggest influence on quality. Don't get stuck and depressed, move on. The fact that you recognise these problems and care about them suggests that your attitude and ability will be recognised and welcomed elsewhere - as it should be.

As the saying goes : "Don’t wrestle with pigs. You both get filthy and the pig likes it."

> The real purpose of what I wrote was a musing (fitting for the Embedded Muse) as to whether branchless processing could be seen as a way to reduce the complexity due to removing branches. I think that even if the compiler was to produce branches under the hood then that would be the case, according to the definition of complexity. Certainly the obfuscation of branchless programming is unlikely to make  the code more reliable.

I would argue that explicitly branchless programming, by the usual methods of "select between two results based on a condition" or "conditional move", usually DOESN'T reduce cyclomatic complexity.  The fact that it ALSO usually impairs code readability makes this a double-whammy, since poor readability leads to more bugs being introduced.

The reason is straightforward: you still have two mutually exclusive paths of computation, and the only way to exercise both of them is to run at least two distinct tests.  Never mind that all the instructions get executed in both paths; the result of one path is rendered invisible when the final result comes from the other path.

There are cases, however, where writing code in a branchless form IMPROVES readability and PREVENTS certain types of bugs. In particular, C's ternary operator directly expresses this construct in a way that ensures that, no matter what the condition is, SOME value is assigned.  Good compilers will be able to convert this into a register-select, a conditional move, a pair of conditional stores, or plain old branches depending on what works best on the target CPU.

For example, this function might come up in machine learning:

float  ReLU(float x)
              {
              return  (x < 0) ? 0 : x;
              }

 ELU(float):
              vcmpe.f32 s0, #0
              vmrs        APSR_nzcv, FPSCR
              bxpl         lr;  conditional return
              push       {r4, lr}
              bl         expf
              vmov.f32 s15, #1.0e+0
              vsub.f32 s15, s0, s15    ; slight inefficiency here
              vmov.f32 s0, s15
              pop        {r4, pc}  ;  unconditional return

 ReLU(float):
              vldr.32 s15, .L15
              vcmp.f32 s0, s15
              vmrs  APSR_nzcv, FPSCR
              vmovmi.f32 s0, s15 ;  conditional move
              bx  lr

 .L15:
              .word  0