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.

Production-quality Code Tests

This post is all about the code test and development interviews. For software development jobs, our craft is programming and to be a great developer you have to be a great programmer. Is it that straightforward? It really is.

The Code test is your first impression

Don't count on previous experience being known to your potential new teammate. We all have histories, and when you have put down lots of good work it may seem obvious that you know what you are doing. That may be obvious to you, but your assumptions about how good you actually are just that; an assumption. Put yourself out there and get real feedback. This is how you know how obvious this reality is to others.

My big mistake in my last code test was approaching it in the manner I send code tests to new employees. These have been new grads and co-ops, so the audience (me) is looking for how someone approaches and solves a problem; and all the gory details along the way.
For a company that is established, and growing fast, the priority isn't in new products or prototypes. They have a product and need people to grow it with quality code that doesn't need to be re-visited and re-factored. Reflect this reality in your deliverable.

Show an understanding of Done

What I needed to do was find out from my audience what they were looking for in the result; and produce the result to that end. This was for a senior position, so the need is to have someone starting that can add value to the team immediately. This would mean the code would have to be production quality, and why not? If you are hiring someone, you don't want to have to figure out if they can deliver quality; you are aiming to hire people that know how to do just that.

Create trust with a solid deliverable

Be thorough and produce a production ready commit. Assume the highest standard. While it is important to show how you arrived at the solution; for the interviewer it's easier to work back from a finished product rather than stepping through the commits to get there.
Sloppy work will show that you may not take this seriously, so how is that going to work in the day-to-day when your teammates depend on your work to be Done?

What is Done?

Done means different things to different groups. In some environments it may seem ok to have a lower bar of quality when done. Academic environments can be very proof-of-concept work, so it can become normal to deal with code from many different authors and styles. Some groups are in a rush to get to a prototype. Be diligent and don't  let that become your normal in your day-to-day work. Done is when you don't have to go back and fix it; its Done. That is the nature of professional work.

Find the time to do it

You probably have a full-time intense job, and maybe a side gig, and a life with responsibilities. How do you make the time to carve out a new path? Interviewing for a developer role isn't the traditional meeting with people and doing some company research in-between. The company research must be done along with: Domain research to understand the industry the company is in, and a code test. The code test (if it's good) will take some time. Make sure you have time before you interview and take on a code test. Go above and beyond to create the trust in the new relationship.

Changing environments can be challenging

When switching to an entirely new language and platform; it can be challenging to catch up. In catching up and figuring out your new reality, there is a big different to being fairly proficient in the new platform, and being production-quality ready. Once you get some momentum in the new environment, find some code tests to try out and see how production ready you are.

Find the fit

Work is a relationship, and sometimes what seems to be a 'good fit' on paper may not reflect the reality. What stage is the company in? is it searching, scaling or mature? There are different personalities needed at the various stages. In the early days there is a need for visionaries, but in the mature company that person may become a disruption. A drone worker in a startup still searching for market-product fit will slow the group down. Decide what you want to do, and understand who you are, before approaching the company.

Goals for the code test

The main goal for the code test is to establish one very important relationship trait: Trust.
The candidate needs to trust the group they are applying to join, but only when the candidate gives a reason for them to be trusted will this happen.
Show quality in your deliverable and show your craft in the highest possible light to put both of you on the best path for a long professional relationship.