Introduction 

Building on Joe Ackert’s article “Tools for the Toolbox”, one of the items that he talks about is “Providing Value”. Providing value as an engineer can help you grow your career and move up the career ladder. However, career ladder descriptions on what you need to do to provide that value can be quite confusing.  There’s the usual cryptic guidance of “Own the Feature” or “communicate effectively”.  

To help understand this guidance, “What does that look like?” is a phrase I like to use. For example:  What does ownership look like? Or what does it look like to communicate effectively? I’ll take this question and show you what providing value looks like while helping you to understand the cryptic career ladder descriptions.   

For this example, your manager approaches you after and says, "I need you to own the new user profile feature." As a web developer, you're tasked with creating a page where users can view and edit their personal information. What does owning this feature, driving it, and communicating effectively look like? 

Software Design 

The initial step of writing software after the requirements are written is usually software design. Owning the solution isn’t just writing the code, it’s about making sure the feature meets the customer needs, has high quality, and is delivered on time.  You could say, that’s the job of the product owner, or the job of QA, or the job of the database team. However, in owning the solution, an effective developer makes sure this all happens in a way that works well with everyone.    

Clarify Requirements: You may have already reviewed the User Story with the team. Often, you’ll need some clarification during the sprint. Instead of sending an email or slack message and waiting for the response, have a conversation with the product owner to clarify any acceptance criteria: Perhaps the team missed required fields.  How should errors be handled? Are there any compliance or security considerations for user data?   

Ownership is understanding the entire solution so you can complete a thorough design with the team. It’s also not waiting for clarification which could cause delays but reaching out directly. Effective communication is also better in person/on a call.  

Involve the Right People: Loop in the team members working on the feature early to discuss how data will be fetched and updated in the database. Set up a time with the UX/UI designer to go over wireframes. Don’t wait for the scrum master to set up these discussions.  

You’re owning the feature by setting conversations up yourself. Moving forward without waiting. And you’re communicating effectively by reaching out to other team members or keeping people in the loop with updates through Slack or in meetings. 

Collaborate to Identify Dependencies: Make sure everyone on your team and other teams knows what technical pieces are dependent on each other and follow along on the progress. If the backend API is delayed, immediately flag it and suggest alternatives for the UI team (like stubbing data locally).  The ownership is in the proactive, effective communication on the dependencies and specifics of the design.  

As you can see, ownership, effective communication and providing value are all tied together. The difference between an engineer that provides value and an engineer just doing the minimum is you’re not waiting for problems to be solved by the project manager or scrum master; you’re anticipating them and addressing them. You’re also communicating well by ensuring others are aware of the possible impacts to their work. Working with other team members directly can provide value and be far more efficient than asking the project manager to schedule and document the meetings for you.  

Implementation 

Now that all dependencies have been identified, any sub-tasks have been created and the software design is complete. Start working on the development by simply grabbing the high priority tasks off the backlog. Don’t wait for the scrum master to assign it to you.  

Reach Out for Help: If you’ve been working on connecting the frontend to the backend API for updating user data, but you’re stuck with a weird error that keeps throwing 500 status codes. After 45 minutes of debugging, you can’t figure it out, reach out without delaying.  Ask the backend developer for help. Don’t just say, “It’s broken.” You come with context: "I’m seeing 500 errors when trying to update the address field. I’ve traced it to the JSON format, but I’m unsure why it’s being rejected." Try everything within reason before asking for help, and when you do, come prepared with specific information not just the problem. I’ve found that 99% of the time someone else knows what the problem is. Or, if they don’t, talking through it with someone else helps identify it.  

Follow Up: As the implementation progresses, follow up with the other team members if needed by sending a quick Slack message to confirm their API will be ready for integration by Friday. Look for a response of some sort such as the eyeballs or a thumbs up. Referencing an individual directly and looking for a response helps with communication because then you know they received the message.  

Offer Solutions: If a task is getting behind, hold other team members accountable by following up on deliverables with help from the project manager. The project manager would track the progress or changes to the plan, you can provide recommendations on how to move forward. Message the backend lead, "Hey, I noticed the API isn’t up yet. Are you running into issues? I can adjust my timeline, but we need to figure out a plan, so we don’t block the feature release. This is good communication and ownership. You’ve identified a problem and worked with other team members on how to address it directly. If there is a delay, you can report back to the project manager with updates directly saving the Project Manager time.  

Help Others: Owning the implementation doesn’t necessarily mean writing code yourself. It also means helping other team members with their work as well. If you can help 3 other team members improve their efforts by 10%, you’ve got a 30% increase in team effectiveness over just doing it yourself.  

Report on Progress: As the implementation progresses, communication shows up in small items such as administration, too.  Throughout the development be sure to update the JIRA tickets to reflect that the frontend and backend are integrated, note any pending tasks like further testing or accessibility adjustments.  

Report when tasks are done right away. If you’re done with a piece of code early, you don’t need to wait until the next morning’s standup before letting people know. Post an update in Slack: "User profile page is functionally complete. API integration done. Final testing in progress, on track for next week’s release." 

As small as it may seem, keeping your tickets, timesheets, and stakeholders informed without needing a reminder provides value. None of these tasks take a significant amount of time. They all help with communication.  When a product owner or manager must go back to you to keep the tickets updated or ask about details that you could have communicated, it takes additional time and effort that you could have saved with a simple message or update. 

At this point, the amount of effort an engineer spends on a feature starts to diminish, but providing value through ownership doesn’t stop. On to testing and deployment.  

Testing and Deployment 

As the feature goes through the next steps from functional testing, through integration testing and on to user testing, reach out to make sure the other team members have what they need to test.  

Follow Up on Deployments: Reach out to ensure the deployments are successful, testing team members have the data they need or answer some quick questions to move things along.  

Follow up on Metrics Yourself: After the deployment, follow up on the expected improvements on the metrics. Perhaps the response time of the web service goes down or the conversion rate of purchases goes up.   

“What does owning a solution look like?” 

Answering the question of “What does that look like?” results in looking for actions you can do to provide value. In this case, it’s all about owning a solution and providing value. It may be other things.  

Providing value to a project is not only completing a task but also leading the effort by looking for actions to help move forward on the project. The following list is a good start, but by no means is it complete.  

• Proactive communication 

• Provide updates without waiting to be asked  

• Follow up on requests yourself without waiting very long 

• Collaborate with people that may be affected by the new feature 

• Do your own problem solving.  

• Bring options of solving a problem to them along with a recommendation on the solution. 

• Assisting other team members through challenging tasks.  

• Reach out to other teams yourself 

• Ensure deployments are successful 

Look for your own ways you can move the project forward by acting. That’s what providing value and leadership looks like.