Software developer on steroids - Level 2

Getting from a Jr. Software developer to Software developer Level 1 might have seemed like a long way to go but this is just the first step for a Software developer career in ApexSQL and all the future steps have even steeper learning and growth curve

If you've certified as a Level 1 dev then it means:
  a) You've been working in a fully functional team the company can rely on
  b) Have been a leader at least for a specific task or a goal within the team to carry your own weight
  c) Have gained enough experience with how we work and have already mentored other colleagues or can do so now
  d) You've grown and developed your hard skills just enough so that for any new challenges you encounter you already know how to approach resolving them even when it requires more learning
  e) You are successfully saving time to stakeholders and are working with them vs. working for them or thinking there is us-and-them

Time period

How long will it take to get from the day 1 in ApexSQL to a Software developer Level 2 will depend on each person individually - if you started as a Jr. Software developer (Level 0) then you'll need at least 3.5 to 4 years to be able to check off all of the items below

No regression

The first expectation is that you constantly confirm the level you're currently at which means you don't regress by no longer doing the work you were successfully doing before, or by doing it slower (i.e. you caught lazies)

If you had regression in your performance then it is critical to first make sure you get back on track and have consistent high performance of at least 3 or more months in a row - not doing so risks actual regression back to a Level 0

Soft skills + 1

When doing a Level 2 values review expectations will be one step higher than those for a Level 1 performance review

If you had a "Needs improvement" score for any of the values but have still managed to certify for Level 1 then those values if not improved in the meantime will read as "Unsatisfactory" during the Level 2 review which is a showstopper

If you had a "Meets expectations" score for a value then you need to have displayed consistent or improved values match in order to keep reading "Meets expectations" for the Level 2

Hard skills++;

Jr. Software developers can best testify the amount of new development knowledge and skills gained when going from Level 0 to Level 1 - the same goes for a Level 1 dev aiming to certify as Level 2

Each team has a bit different hard skills requirements depending on the owned product set so the only common metric here is how have those hard skills helped you be more efficient during work

Success = results / time;

The better hard skills you gained then you'll contribute to your team with more results over less time

Value added time saver

Can you confirm all of this:
  1) Are you self-sufficient enough so that others don't need to "manage" you by asking questions and giving directions / frequently correct you
  2) Do you communicate proactively and in an actionable manner with the stakeholders / no surprises caused by you and your team
  3) Do you educate stakeholders and provide suggestions and guidance yourself
  4) Can you be a role model for all Software developer Level 1 peers

Achievements

Additional information we should put on a table before starting the perf review for Level 2 is the list of achievements you can brag about since you've certified for Level 1

If you don't have anything exceptional to show for as a Level 1 dev then how can you justify you have earned the next level

This is also a great personal litmus test you can do for yourself before reaching out - are you able to provide a list of at least three achievements that you are proud of during your Level 1 tenure?

But don't say that i.e. you're proud of showing up for work every day or that you've managed to complete 3 sprints in a row as these are just normal everyday expectations so you won't be doing yourself a favor

For example:
  a) Took initiative to build a component / engine / feature which helped the team by ...
  b) Improved communication of the team with the stakeholders
  c) Helped the team achieve PUQ superiority by fixing X bugs in Y time / by improving performance by x% / by identifying and fixing usability issues
  d) Mentored new colleagues so that they have achieved ...
  e) Suggested [and helped implement] a feature / functionality that directly helped with Platinum goal
  f) Successfully managed X subcontracted projects
  g) Worked with team SEs to ensure uninterrupted team content flow
  h) Took ownership of a standard and helped everyone enforce it

Also such achievements are good to have but aren't the ones we're looking for:
  a) Learned to write thread safe code like a boss - good for you
  b) Read 3 books on design patterns - congrats
  c) Went to a .NET conference - nice
  d) Learned angular / js / css - great if it'll help you get the job done, but the focus is on the achievements that are "done" and have directly helped with your team and the company goals

Jr. Software developer trial period breakdown

Trial period length

Jr. Software developers have the longest trial period when compared to all other roles at ApexSQL

Many of the guys who start at this entry level position have no previous work experience or at least no experience in software development jobs, and have a limited hard skills set

Improving hard skills and earning experience is only possible through actual work by developing products and taking part in ideally every step of the product new version life cycle covering the concept, analysis, roadmap, design, development, testing, release, and agile support

ApexSQL is made of guys who are dedicated and see themselves in the IT battle trenches for years to come by sharing both success and failure with the rest of the company

How long it will be until you complete the trial period it'll mostly depend directly of you, and of your team, but specifically trial period for Jr. devs with no previous experience is usually 9-12 months and depends on your growth curve, team achievements, and individual results 

Specific requirements

0) To even start talking about successful end-of-trial it is mandatory for all our devs to read in full and to share on the subject of The Inmates Are Running the Asylum book.

This step is also a prerequisite for any software design and usability improvement discussions / tasks

1) The first step of each performance review is that the team (a product team consists of both devs and Support engineers) must have a good standing and good results at least for the past 3 months.

This comes down to successful ownership of team products by:
  a) Having good team transparency: no surprises for stakeholders; share proactively - raise suggestions vs. asking questions or providing one-sided decisions
  b) Don't expect to be told what to do and don't allow to be asked what you're doing - if someone asks for an update then it is already too late
  c) Ideally have a few product releases under your belt - not all teams have this but it is a good achievement to have if applicable
  d) Uninterrupted new content flow - this part is owned by team SEs but if they get stuck it will come down to devs in the team to help out even though we'd like to avoid this as devs should focus on development work


2) The second step of the perf review is to have good individual results that speak for you and to actually own some team goals.

One option is to became a go-to guy in the team for a specific area, to directly contribute to your team through learning and sharing about a specific area, subcontract management, QA and test automation, development/implementation of a specific engine or technology, or something else.

This doesn't mean to isolate other team members from an area of code or to work alone in isolation as that should never happen, but instead take ownership of a goal within the team and with the help and collaboration from the team you complete it from start to finish

And most importantly share regularly about your team and individual achievements and progress - don't expect someone will be spying on you or monitoring your every step; no one will notice if you don't share for yourself

Also don't hide behind other team members - there's no such thing as a team lead in ApexSQL or a team PR

Owning a goal means you won't wait on everything to be reviewed by everyone else in the team and to reach a "consensus" - help is welcome and collaboration is good, but you should never wait on anything or anyone and should take full responsibility for the goals you own

3) The third step is values review from peers, mentors, colleagues, stakeholders - just read our Working Naked values statement and let me know if you have any questions

4) The final match-80%-of-job-level-requirements step is not required for a successful end of trial for devs as certifying for Software developer Level 1 requires even more battlefield experience and hard skills which can be ideally achieved in the next 6-12 months at most 

Benefits

Upon successful end-of-trial performance review Jr. Software developers remain Jr. devs (Level 0) but gain paid vacation time proportionally for the given year, and are paid during the month for the ongoing month (vs. at the end of month)

Later on when you finally certify for a Software developer Level 1 it comes with commensurate increase in salary, and depending on the current company policy also covered local contractor monthly taxes and insurances 

On the right track

Ask yourself:
A) Is my team proactive enough, do we get many questions from stakeholders or we're able to anticipate questions by regular sharing of our status, plans, and recommendations
B) Are we sprinting regularly in the team, learning from our failed sprints, and doing everything we can in order to succeed each of the team sprints
C) Am I contributing in my team by sharing responsibilities with my colleagues without skipping out
D) Am I there for my team members when the going gets tough
E) Am I sharing regularly with the stakeholders for both my team and myself, or am I expecting that others in the team will be sharing for me
F) Are we (devs) helping our team SEs with customer support and with content. How is my team SE doing right now
G) How much did our team and I contribute to the company when compared to other Jr. Software developer teams / individual devs
H) Am I repeating mistakes or am I learning each day so that my next day is always better than the previous one

What next

Reach out to HR and/or Facilitators whenever you have any doubts or when you lack feedback

Otherwise we'll keep an eye out and touch base when we consider you ready for a potentially positive first performance review

The art of project management

Ok, so you've figured out what work to subcontract and have found a potential freelancer who will consider doing the work - congrats on learning the art of subcontracting basics, now comes the actual project management

As we already determined that every member of our product team is not just a PO but also a PM, below are a few PM operational algorithms that will help you to ensure your project is successful


Project takeoff

  1) When you have project specs vetted by the team (SSE, devs, others as needed), send the specs to the selected tried out subcontractor, or send the specs to Ops for assistance in finding a subcontractor with the best bid

  2) Subcontractor will usually have some questions about the project specs before providing work estimates
    a) If the answers to the questions are already covered in the specs that means the subcontractors didn't bother to read through the specs and you can dismiss them
    b) If there are no questions at all or no questions you hoped to hear then make sure to ask a few "control" questions of your own, i.e.: how do you plan to implement something, what do you suggest for a solution for this problem, which technology will you use to accomplish this, did you work on a similar project before, etc.
    c) If you get some very basic questions about the project that should've been covered by the specs already that means that the specs aren't good enough and my suggestion is that you don’t waste time in ad-hoc discussion with the subcontractor but go back to step 1) to rewrite/update the specs to cover all important information and then send the new specs to the subcontractor

  3) After the subcontractor provides work estimates and project ETA, perform a sanity check
    a) If you don't agree with some of the estimates don't challenge them directly but simply ask for a more detailed breakdown and explanation how did they come up with such an estimate
    b) Be constructive when talking with subcontractors, it isn't your goal to reduce the estimates but to make sure both sides are fair and professional: you are an employer but you need to treat your subcontractor as your partner

  4) Once the project estimates are good define project milestones as these are critical steps along the way that will allow you to track the progress and to avoid situation where you reach the project deadline and figure out it isn't done right
    a) Although we don't pay out $ when a project isn't done or done right, we still have growing opportunity cost caused by the delays which can be greater than the actual project cost
    b) Each project can be broken down into several milestones with no exceptions (like a sprint PBI can always be broken down into smaller tasks)

  5) Get in touch with Ops for assistance with securing project finances

  6) As soon as you have a formal approval for the project, agree on a hard date with the subcontractor by when the project will be completed, and by when the first milestone will be delivered


Project cruise

  A) If the subcontractors have any additional questions about the project at any point along the way, make yourself available to help out as soon as possible
    a) Insist on written communication whenever possible, especially if you discuss changes in the project requirements; use Skype only when it will save you time but have all project agreements written down in case we need them later on
    b) #EveryoneThinks applies to the subcontractors as well - don't solve problems for them but instead always ask for them to suggest and explain the best solution that you'll review and approve or suggest differently

  B) If you uncover additional work is needed for the project along the way that wasn't covered by our original requirements go ahead and immediately discuss project appendix estimates with the subcontractor and let Ops know to assist you with financial approval
    a) Be fair - if you didn't ask for that work in the original specs then don't insist for subcontractors to do it for free

  C) Make sure you know the upcoming milestone ETA as well as the project completion ETA at all times
    a) If the subcontractor misses an ETA you need to send a follow up immediately
    b) If you don't hear back from the subcontractor send another follow up and add Ops to CC to help out
    c) If someone wakes you up in the middle of the night you need to be able to immediately provide project ETAs and status

  D) #EveryoneShares - be transparent towards all stakeholders (i.e. Facilitators): if you are asked about project status then you're already late
    a) Push information when a milestone is approved
    b) Push information when a defined ETA is changed for whatever reason
    c) Push information when additional project requirements are uncovered

  E) As soon as you receive a deliverable from the subcontractors prioritize reviewing it and providing feedback
    a) If you need some time to review the deliverable provide the subcontractor with an ETA - what you expect from the subcontractor about giving and honoring ETAs applies to you as well
    b) Check deliverable conformance to specs, functionality, quality, performance, code where applicable
    c) If something isn't good enough send it back with sufficient feedback
    d) If a deliverable meets all of the milestone acceptance criteria inform Ops and the subcontractors about it to cover the financial side of the milestone


Project touchdown

  1) Project is officially complete as soon as all milestones are approved and all project requirements are fulfilled - you determine when this happens by giving away final project approval
    a) Don't give an approval if you haven't allowed all team members (devs, SSEs) to review the deliverables and to report all found issues, provide feedback
    b) Don't give an approval just to end the project sooner if there are still remaining issues - be persistent for the subcontractor to resolve all of the known issues
    c) When in conflict with the subcontractor whether an issue is a bug or an additional request feel free to consult with Ops, but also remember that we need the project 100% completed as soon as possible with the highest possible PUQ so if a small additional project appendix will get us there don't think twice about it and err on the subcontractor side
    d) Always remember: the more things subcontractor didn't finish the more work for you

  2) Never stop thinking about additional work you can subcontract, especially if you're happy with the subcontractor
    a) Spin off a new project immediately if you already found additional work needed for an R2, R3, Rn down the way
    b) When applicable ask the subcontractors to do some comp research on their own and to suggest any missing features, areas where we can improve the project - senior guys who are looking for additional work will be happy to help you out with this


Key things to remember

  1- You are the project manager and you own the project from start to finish
  2- Ops is always there to help you out with administration and PM advice whenever in doubt
  3- Don't be afraid: Failure is ok, fear isn't ;)

Scrum tales - part 15 - success FAQ

Why does Scrum matter?
- Scrum provides structure and forces prioritization in the company
- Scrum provides maximum work transparency at all times
- Scrum provides clear insight into problems within teams
- Scrum eliminates team leaders and administrative non-thinkers
- Scrum enables regular dialog between stakeholders and teams
- Scrum allows teams to make their own commitments and estimates within reason
- Scrum allows teams to work without constant supervision and guidance
- Scrum allows for predictable work increments
- Scrum is easily scalable

Why do successful sprints matter?
Each successful sprint carries a potential production-ready deliverable increment (a new product build, a specs or a prototype for a new tool, documentation, etc.), and as each sprint is time-boxed it is easy to make systematic progress and be competitive as a company

What happens when a sprint succeeds?
It shows that a Scrum team cares about the company success and can be trusted more in the future as the team has delivered what they agreed with the stakeholders

What happens when a sprint fails?
It shows that a Scrum team needs to improve in the future, and gives the team a chance to accept responsibility and address the organizational issues themselves

Is it ok to fail a sprint if it is done for a greater cause / higher goal?
No - saying "greater cause" in this context is an excuse for doing things your way without alignment with previously agreed goals and priorities, and with lack of transparency towards stakeholders

There are no valid reasons why a sprint should fail if:
  a) Communication with the Product Owner and all stakeholders was regular
  b) All issues with suggestions how to resolve them were raised as soon as they showed up
  c) Sufficient effort was expanded

How to ensure a sprint succeeds when unexpected issues show up?
As soon as the issues show up:
  1) Consider all possible solutions to keep the sprint on track: additional research, workaround, help from other teams, or just expand some extra effort
  2) Contact stakeholders / Product Owner to inform them of the issues and possible solutions
  3) Recommend sprint grooming as the last resort

Both the Scrum team and all stakeholders equally wish for each sprint to succeed so consider all related communication as discussion between allies on a common quest for success

Hard sh** and smart sh**

Great GSD ("Get Sh.. Done" as ApexSQL Nis office central poster says) = consistently have both short term and long term transparent results

Some teams are working using Scrum work organization through goals (answer to what?) and tasks (answer to how?), while others have monthly goals / quotas to achieve by making daily and weekly progress in smaller increments

We often forget about the goals while focusing exclusively on the tasks at hand to get them finished no matter what, forgetting about what is actually needed in the end and in what time

Now I'm not saying that focusing on daily tasks is wrong - one of my own email quotes from the early days said:

"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it." - John Carmack

 

We must always keep in mind both the goal and have Daily deliverables at all times

But in order to grow, besides working hard we must also be cognizant of the end goal at all times and be able to work smart to achieve the goal

GSD has two levels:
   1) Hard Sh**: daily deliverables, things we must all do our part and complete in order to make daily progress, i.e. fix stubborn bugs, test bug fixes and report new bugs, write TS articles for unfixed bugs, publish articles, communicate with stakeholders, share your progress daily, etc.
   2) Smart Sh**: make a dent in the universe by aligning all action with end goals and complete the goals with a reasonable amount of effort in a reasonable amount of time

How does Smart Sh** translate to your everyday work?

   a) Dev teams should realize that customers don't have a use for 50 bug fixes in code and would much rather prefer 20 bug fixes in a product build they can actually download - know when to cut and deliver.
   b) SQA should invest time to understand product usefulness, to learn about it and to use it as customers use it in order to test the product well, to never assume they know everything, to write about it in non-hamburger helper way, and to excel in customer support.
   c) Everyone should be investing time into ERF mentorship with new colleagues so that they can start contributing back and in turn save time to you.
   d) Everyone should automate repetitive work - currently a huge soft spot in multiple teams.

What does automation have to do with working smart?

A lot: one of the funnier historical examples is several devs going rogue and writing a software that fully automates sending Daily Scrum Summaries - while other teams were taking hours of time weekly to manually compile good Scrum Summary emails, these devs took one day and created a two-click solution that in turn saved them days of time; I always received spotless Scrum Summaries from their teams which was a mystery to me until I found out about the "plot" ;) (devs are good guys, they were planning to distribute the software to everyone when we stopped sending these emails daily)

 

Time is a limited commodity so by investing some in order to automate repetitive work (smart vs. hard), devs gained more time to focus on what really matters: to write better code and to deliver great products to the customers in order to make a dent in the universe. I'm also sure devs had more fun in the process ;)

Ultimately whatever we do we must ask ourselves:

   A) Can I complete the task at hand more efficiently with less effort and time?

   B) What goal will be closer to completion when I finish this task today?

   C) What will I deliver to customers when the goal is completed?

   D) Will the customers pay me for the deliverable?

 

If no one will pay you in the end, why would you do it in the first place? ;)

Actionable inter-team deliverable approvals

Every Scrum team has either asked other teams for help with deliverables review or has provided assistance by reviewing deliverables of other teams

This inter-team collaboration encouraged as it will in turn improve inter-team communication, speed of deliverable reviews and most importantly quality of deliverables

However before Product Owners can accept a deliverable as approved, we'll need to see that the team performing the review has actually invested time to provide constructive and actionable feedback, or we'll automatically assume that deliverable isn't to expected acceptance criteria

What does this mean in practice:

Scrum team being reviewed - help reviewers to help you:
   a) Explain to the review team the intent behind the deliverable
   b) Specify areas that must be reviewed in a structured way
   c) Note what kind of feedback you need in order to have the deliverable approved

Team performing the review - provide full information in your reply:
   a) What has been reviewed
   b) What should be modified/updated/clarified, or
   c) Why nothing should be modified/updated/clarified (less likely)
   d) Recommend whether the reviewed deliverable should be approved or not by PO

Why should a team spend time to review other team's deliverables if they are not direct stakeholders? Our Company values statement says that Everyone serves: "Treat everyone as a customer, internal or external, and make responsiveness part of your personal brand. Build effective working relationships with a focus on being positive, informative, actionable, and helpful."

 

Leave-me-alone type of replies such as "Approved", "We have nothing to add", "This is good", and similar won't count as reviews at all when doing Sprint review

Everyone strives 101

Recent latest addition to our company values statement says that Everyone strives meaning everyone should be productive, focused, driven, and motivated. What does this mean during your everyday work?

 

   1) Focus on results - always know your end objective, whether you are working on a sprint goal or you have an unplanned ad-hoc task to finish. If at a time you feel like you don't know where to start or what should be the next step to get to the finish line, stop for a second and remember your end objective (new product build, analysis recommendation sent, documentation written and published, etc.)

 

   2) Expend the effort / go down with a fight - for various reasons we all get into time crunches to deliver. If you're already under pressure, worst thing you can do is to give up by "knowing you cannot finish on time" or that your "core hours have passed"; I've heard this far too many times, everyone is suddenly an oracle (no pun intended) and prefer to give up rather than go down fighting.

Working a few more hours killed no one and most of the time it is just enough to achieve your goal; even if the goal isn't achieved on time, you'll be able to finish it more quickly in the next sprint / next day

 

   3) Use time efficiently / demonstrate consistent productivity - on the contrary to the popular belief that you must always work overtime in order to deliver, simply remove time spenders from your everyday work; distinguish activity from productivity, just ask yourself: "What would happen if what I'm doing right now never gets done?" - this will help you uncover time spending tasks that lead nowhere

 

   4) Prioritize effectively - this is easy once you get used to it; just focus on your priorities - top PBI in your sprint, High priority bug, High importance email, etc. and you can never be wrong. Working on a lower priority task just because it is easier or quicker to do is always wrong - this happened so many times and although you may have a deliverable in the end, it will never be the right one

 

   5) Identify risks early and work to overcome roadblocks - "It was blocked by XYZ" is the most common reason for not getting something done on time; again in most of the cases it could've been prevented if this same goal was better prioritized and raised early. To fix this just use your brainpower to think of risks and prioritize those tasks before you start working - using brainpower afterwards to think of an excuse is a waste of time

 

   6) Single task - focus on exactly one goal and complete one task at a time before moving on to the next one. Yes, it is that easy

 

   7) Focus on daily deliverables - if you're about to shutdown your workstation, ask yourself: "What all have I delivered today?" - if you're having hard time thinking of an answer, reconsider the shutdown

 

   8) Set expectations realistically and expend the effort required to meet them - in almost all cases you have the freedom set your own ETAs - these are sprint Task estimates defined by entire Scrum team on sprint start, or ad-hoc task ETAs you provide when answering an email. Still it happens that you "overcommit" making it the second most common reason for not getting something done; even if you do overcommit, it is your responsibility to kick it into a higher gear and achieve the objective, but also to learn from it and improve your estimates in the future