How individual contributors add value to technology teams when not managing people

Building software products is a team sport, and there are many positions to play on any team. In software teams, technology leadership positions have evolved over the years from primarily people management to a combination of personnel and technology management.  It’s difficult for one person to fulfill these distinct responsibilities successfully; as a result, successful teams have split this role into two:  Engineering management is people management, and Staff development is focused on technology production. 

The success of the team is dependent on the people involved, and the understanding of the goals they need to achieve. The Engineering manager enables an understanding of these goals, enabling teammates to play their positions more effectively. This develops the person. 

The individual contributor isn’t the coach; they are more like the team captain and they show by example how to fulfil the responsibilities of the position. This brings other developers up to a higher level of quality development. The Staff developer moves the technology forward. While the specifics can vary from team to team, at their core, they must fulfill the fundamentals of: 

• Technical excellence, by example
• Predictability of delivery for stakeholders 
• Ensuring Architecture quality through collaboration on design and review 

Technical Excellence, by example

A staff developer must show technical excellence by example and how to move development forward with quality and velocity. This effort is not just building a feature, but engineering the feature so that it has the quality needed for the product to be successful in the market. 

Starting with the code and showing guidance and practices for maintainability and portability with pull requests that follow a declared set of quality attributes that guide quality code. What is quality code? Code that follows common conventions that the group has decided on. This is formatting, linting and type safety so the code in the product is something everyone can recognize. Remember that the code isn’t the developer’s code, it is company property and must be maintained responsibly so that any developer can work on it. Working through pull requests by making sure the collaborators can review and push the code to production in a common way. There will be unknowns to figure out, but it’s necessary sometimes to run into the dark room and light it up together.

https://jseller.blogspot.com/2020/03/packaging-code-for-development-and.html

https://jseller.blogspot.com/2023/06/maintainable-and-portable-codebases.html

Staff developer Improves predictability by reducing scope. 

Understanding the context to help build features for the user that are valuable. To move the product forward, understanding the impact of the decisions helps the predictability of the process and communication during design implementation

The smaller the better and output an implementation Epic to understand the definition of done for this enhancement. Work that implementation to production.  Use feature flags to enable this functionality to the user when releasing to the production environment

https://jseller.blogspot.com/2019/01/software-releases-are-lot-more-than-code.html

Ensures architecture quality and collaboration on the definition of that quality

Operationally the Staff developer ensures a high level of adherence to the quality attributes of the system. The functionality, does it have some understanding of the problem we are solving for the user? 

Collaborate on functionality, observability, and the tools and processes that enable easy maintenance of the product in production. Adhering to known standards establishes good practices and processes. 

https://jseller.blogspot.com/2019/01/feature-definition-with-quality-model.html

Does the solution have a coherent definition of the functionality and acceptance criteria? Staff developers know they can’t build the whole thing in one change, but able to break down the solution into smaller chunks and gain agreement on the smallest definition of done that shows the value

• https://jseller.blogspot.com/2023/06/effective-software-architecture-meetings.html

Evolving the architecture together

To support any functionality there will be changes to the architecture. Develop a strong culture of design through a standardized process of RFC (or ADR) review in the team. 

• system requirements map to unit tests so the understanding of the scope is clear. 
• build tests from the acceptance criteria for integration testing in the development and staging environment
• build sanity/smoke tests to validate this functionality in the production environment
• build observability, performance, security, and portability from these small changes, 
• Working with living specifications enables async collaboration. Keep these documents concise and to the point. 
• Good design ‘fits in’ to the system, use diagrams for containers, and components. that are new or changes
• https://jseller.blogspot.com/2023/06/consistent-software-design-enables.html
• https://jseller.blogspot.com/2020/02/communicating-software-architecture.html

Wrap-up

Staff development brings an awareness of the product and company’s goals to technical development. This ensures the teammates can align on the architecture and collaborate at scale to deliver a quality product. This direction, and most importantly, the collaboration with the team members, ensures that the product produced can fulfill the goals of the company’s place in the market.

Effective Software Architecture meetings

For an effective architecture strategy to develop; there needs to be some alignment when meeting together. In meetings with no agenda or focus it can seem to be a waste of time. It is. if the meeting invite is “we are going to brainstorm on everything” then meeting fatigue will set in and participants will have less engagement.

Its also essential to be clear that this isn’t a status meeting; the status is on the board, backlog and roadmap. Those are the outcomes of these meetings. The status should be visible without a meeting.

The common goal/output of the meeting is some decision on how to move forward with alignment of the participants. To set the theme and get an output of the technical meeting to be an effective one; its essential to understand the context of the meeting, and the participants.

Problems and Solutions

How to enable problem solving and know the valuable problem is being addressed? How to enable decision making so that we have a solution to work with and con move the understanding of the problem and our technical solution forward. Communication is a lot of listening and focusing on context

Focus on Context and Outputs

Meetings and the audience

For any meetings you have; take a moment to understand the Goal of the meeting, and from that it should be understood what you are working with here. Its also nice for any participants to know the context if they have some topics to bring up, or to be a listener in the background; or not participate at all

Discovery

Product discovery meetings are key to understanding user problems for features; and the deeper understanding of the technical constraints for this new feature.

These could be from ideas from business, dev, product, or triaged from a customer issue or suggestion; but the rationale for adding or modifying the architecture should be rooted from something that creates value in the product.

These output to the Roadmap level, product or technical; and sometimes need a prototype or more investigation to qualify the actual goal (and motivation).

Outputs

1. Valuable problems
2. Feature value
3. Market direction
4. Business Impact

Audience

• Product
• Sales
• Support
• Development
• QA

Planning

You have discovered the valuable problems and understood the value solving that problem will bring. Now its time to plan the technical solution; to creating the requirements and design for system features. 

User story mapping is really helpful as this stage as it uncovers the quality attributes to support this new feature. Also at this time trade-offs are made, so be mindful of any debt you are going to put on the books. Debt is useful, but like any debt it will overwhelm you if not kept in check.

As you go a long, you will learn more, so this meeting works well as a regularly scheduled meeting. In agile this is usually a "Backlog grooming"

Output

• Backlog items for functionality
• Technical spec
• Architecture Decision Records (ADR)

Audience

• Development
• QA
• Product

Implementation

The backlog has items for the functionality and the tech spec has the designs and decisions made. Lets build this thing! This is usually called a sprint onboarding, a kick-off meeting and gets the project people involved. This is when estimation can become possible with the details of what is being made now down on paper.

Outputs

• implementation Epics for some definition of done
• interfaces for implementation
• how requirements build acceptance criteria

Audience

• Devs
• QA
• project managers
• product managers

Release

Are we releasing work to support a feature, or is this a new one? Release meetings can take on many forms. and again depends on the context. A demo is an internal release and what is in that demo can be used to form the external release. For the technical architecture, the items can be lost in favour of the functional product notes; but its important to keep the architecture in-step with the release numbers you put on the deliverable

Version the architecture with the release

Output

• in the release notes, link to latest requirements that created that version
• Link docs describing features and acceptance criteria
• diagrams of structure
• mockups of UI and flows

Audience

• product
• QA
• devs
• devops
• Support
• Sales

When the meetings happen

There can be a tendency to get people involved, but having the wrong people can really hurt the output. Keep the focus to the group affected. For most architecture decisions its usually the team making the feature, when they plan to do the work. 

For architecture decisions on cross cutting quality attributes (Usability, Security, Performance, etc) its important to have a working group that focuses on setting the policy (a good checklist) for the functional features to get built on

Conclusion

When making the context clear and involving the relevant participants; architecture meetings can be a reliable way to output relevant decisions. Its essential to know What we are making so we can figure out how we make it and when it happens.

By taking a moment to understand the context and the problem to be addresses; the actual people that are needed to participate will become clearer and the chances of a meaningful solution will increase.

Being an effective developer in a company

Lessons learned when developing software in a company:

Add value

• Add value. Look to solve problems, not just build stuff. 
• Be Pragmatic.
• Be a professional; ego trips and flame wars have no lasting value, professionalism does

• Learn, there is always a better way.
• while(developing) { Have a personal process and refine it }
• keep a journal/log/todo at all times. keep a running queue or stack (depending on how you organize)

Be a good teammate

• don't try to keep everything in your head, put designs and thoughts in paper to formalize.
• Extremely high rate of return on information sharing. Collaborate.

• Utilize tools so you don't have to make new ones that do the same thing.

Specs

• Implement to spec. If so spec exists, document. The document is now the spec.
• Writing code is part of the solution, after the problem is understood.
• Write to the API before creating it, make it something you would want to use.

Quality

• Time to do it right. If the time doesn't exist now, when will it?

• Are you making good software, or just trying to make some software work? Making a quick patch just pushes the time to do it correctly into the future. Fixing will make the problem go away forever.

• There is always work to do in areas of performance and code clarity/quality. Schedule this as part of the time spent.

Complexity

• Aggressively attack complexity or it will catch up with you.
• Don't be too clever for your own good if clever adds complexity. Be clever in simplifying. Complexity will cause brittle code and crusty developers, avoid needless mental work in code.

AI can help, if trained to do so

AI can help humanity; but only if it isn't trained with human biases and ideologies. This is the same with raising and training people, but with a machine it could be easier to get better results.

AI is coming for you, or is it?

There seems to be a large amount of both excitement and fear around the emergence of artificial intelligence. Will it take over? What is it? Can it save the world? Those are all very big questions, and for a new technology to generate these sorts of questions and to actually make us question its impact it could have on our lives. This really illustrates just how big people think it is, or could be.

I'll save many of the explanation of AI to much of the published articles and just sum it up: AI is a new brain, we have made a new brain without giving birth to a new person or other organic being, but instead building a machine. This brain has a tremendous amount of capability, but it doesn't have the knowledge required to be useful yet. It need to learn, and be trained.

What seems to cultivate fears in people is the amount of time ti take to provide the brain with knowledge. People take years of care and feeding to become thinking adults, AI machines can seemingly take minutes or hours to learn analogous tasks. Why would we be scared of that capability?

For good or evil? 

How is it that just because the someone is smart that the others around them assume their intentions to be good, or evil? Just because a person can overwhelm another physically or mentally, does it follow that they will? That seems to be a reach, and we might know better by understanding the impact good people have had. It would follow then, if the person knew the difference between good and evil and the consequences of each school of thought; then they would make decisions with the intention of the good. This understanding of not taking a piece of the pie, but instead making a bigger pie and sharing it shows enlightenment of that persons intellect. The training of the AI machine may not be any different.

Are you scared when you meet a smart person? Are you scared when you meet a dumb one? Maybe they deserve the same reaction; but in the meeting of people during the course of a day you will surely generate a lot of fear for yourself.

Decisions, decisions

Why then do people make bad decisions? There are biases that lead them down bad paths. They fall victim to their own deficiencies to justify actions that are vain, greedy, gluttons, envy, etc. They just don't seem to be able to help themselves. The AI brain may present an opportunity to provide decision making that is free of these organic human constraints.

Humans are able to reason and solve problems effectively; but run into difficulties when the brain is clouded by ideologies; whether they are political or religious ones. For AI to help solve us solve some of our own problems, it can be trained to do so; as long as that training isn't an ideological nature.

Bias

Bias needs to be learned. For the various biases that complicate people making good decisions. Confirmation bias, survivor bias or loss aversion; these are learned behaviors and reside in the sub-conscious to be triggered at any time. This can happen without the host really know what is going on.
This is also not consistent. People have bad days, and the anxiety of having a bad (or good) day will affect your decision making. As long as the electricity is on; machines don't by nature have bad days.

To Train AI properly, the validation of the training needs to incorporate not just what the machine knows, but the validate what it doesn't know, and then provide the training so that the machine is adverse to learning the bad habits.

Is this not the same as raising a child or mentoring an apprentice? It might not be that different in what we are doing; but how we do it can be improved to get better outcomes in the decisions the machine (or person) makes.